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Preface 


The VAX/VMS Networking Manual presents an introduction to networking 
software used on VAX/VMS systems. It provides a conceptual description 
of DECnet-VAX software used to access the DECnet network, and VAX 
Packetnet System Interface (PSI) software used to access packet switching 
data networks. The manual explains how to configure and manage the 
network using the VAX/VMS Network Control Program (NCP), the 
primary tool for network management. It also explains how to perform 
user operations over the network. 


Intended Audience 

The VAX/VMS Networking Manual is intended for those who will be 
performing network management functions to control, monitor, or test 
DECnet-VAX and VAX PSI software running on a VAX/VMS operating 
system. The manual is also intended for VAX/VMS users who will be 
performing remote file access or task-to-task operations using DECnet-VAX. 
The manual assumes the reader is familiar with VAX/VMS, but may or may 
not have experience with DECnet operations. 


Structure of This Document 

The VAX/VMS Networking Manual is divided into four major parts: 

• Part I, Introduction to DECnet-VAX and VAX PSI, introduces the user 
to basic networking concepts required to understand DECnet-VAX 
operations, and indicates how the user can interact with the network. 

• Part II, Network System Management, provides usage information to those 
responsible for DECnet-VAX system management, and explains how to 
use the Network Control Program to manage the network and perform 
VAX/VMS host services to remote systems (such as downline loading and 
upline dumping). 

• Part III, Network Configuration, Installation, and Testing, specifies the 
procedures for configuring, installing, and testing DECnet-VAX and VAX 
PSI on a VAX/VMS operating system. 

• Part IV, Network User Operations, describes the techniques for carrying 
out user operations over the network, including accessing remote files and 
performing task-to-task communications. 
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Associated Documents 

The networking concepts and operations described in the VAX/VMS 
Networking Manual are directly related to the following two manuals: 

VAX/VMS Network Control Program Reference Manual 

VAX/VMS DECnet Test Sender/DECnet Test Receiver Utility Reference 

Manual 

DECnet-VAX messages are documented in the VAX/VMS System Messages and 
Recovery Procedures Reference Manual. The procedure for installing the key 
for the DECnet-VAX license is described in the DECnet-VAX Key Installation 
Guide. 

The information in the networking manual is also related to these other 
VAX/VMS manuals: 

Introduction to the VAX/VMS Document Set 

VAX/VMS System Manager's Reference Manual 

VAX/VMS DCL Concepts Manual 

VAX/VMS DCL Dictionary 

VAX/VMS System Routines Reference Volume 

Guide to VAX/VMS Pile Applications 

Writing a Device Driver for VAX/VMS 

VAX/VMS System Services Reference Manual 

VAX/VMS Authorize Utility Reference Manual 

VAX/VMS System Generation Utility Reference Manual 

See also the VAX/VMS Release Notes. 

The Introduction to DECnet manual, not part of the VAX/VMS documentation 
set, provides an overview of DECnet software. 

For information concerning VAX PSI, refer to the following manuals which 
make up the VAX PSI documentation set. 

Introduction to VAX PSI 
VAX PSI Installation Procedures 
VAX PSI X.25 Programmer's Guide 
VAX PSI X.29 Programmer's Guide 
VAX PSI Management Guide 

VAX PSI Packet Assembler/Disassembler (PAD) and Mail Utilities 

VAX PSI Problem Solving Guide 

VAX PSI Public Network Information Cards 

VAX PSI Release Notes 

The following functional specifications define DIGITAL Network Architecture 
(DNA) protocols to which all implementations of DECnet adhere: 

DECnet DIGITAL Network Architecture General Description 

DIGITAL Data Communications Message Protocol Functional Specification 

Network Services Protocol Functional Specification 

Maintenance Operation Protocol Functional Specification 

Data Access Protocol Functional Specification 

Routing Layer Functional Specification 

DNA Session Control Functional Specification 

DNA Phase IV Network Management Functional Specification 

Ethernet Node Product Architecture Specification 

Ethernet Data Link Functional Specification 
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Conventions Used in This Document 

Convention 

Meaning 

SET LINE line-id COST cost 

Example command words are shown in a 
command line in capital letters, and they 
must be entered as shown. Arguments 
are shown in command lines as lowercase 
letters. (In this case, you replace the 
argument shown in the command format 
with the precise information requested.) 


• 

F I 

] RESTRICTED f 
v SHUT y 

Command words or arguments within 
braces indicate that you must choose only 
one of the command words or arguments. 
(Do not include the braces when entering 
the command.) 


SET KNOWN LINES ALL 

SE KN LINE ALL 

You can abbreviate any command verb 
to its fewest unique letters. (In this 
manual, however, commands, formats, 
and examples use the complete command 
words.) 

• 


A vertical series of periods, or an ellipsis, 
means either that not all the data that the 
system would display in response to the 
particular command is shown or that not 
all the data a user would enter is shown. 


LOAD NODE ... 

Horizontal ellipsis indicates that additional 
parameters, values, or information can be 
entered. 


NCP> EXIT 

Command examples show all output lines 
or prompting characters that the system 
prints or displays in black letters. 

• 

|CTRL/x| 

This document uses red lettering to 
indicate all user-entered commands. 

The phrase CTRL/x indicates that you 
must press the key labeled CTRL while 
you simultaneously press another key, 
for example, CTRL/C, CTRL/Y, CTRL/O. 

In examples, this control key sequence 
is shown as ~x, for example, X, *Y, X, 
because that is how the system echoes 
control key sequences. 


[ret] 

A symbol with a one- to three-character 
abbreviation indicates that you press a key 
on the terminal, for example, 1 ret| . 

[opt-arg] 

Square brackets indicate that the enclosed 
item is optional. 
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New and Changed Features 


The following technical changes have been made to DECnet-VAX software as 

described in the VAX/VMS Networking Manual for VMS V4.4: 

• Addition of the capability of treating the nodes in a VAXcluster as a 
single node, while retaining the ability to address each node in the 
cluster individually. The mechanism is the alias node identifier, which 
is a node name or address common to some or all nodes in the cluster. 
The NCP executor parameter ALIAS NODE node-id specifies the alias 
your cluster node assumes. The executor parameter ALIAS INCOMING 
indicates whether your node will accept incoming connection requests 
addressed to the alias node identifier. The executor parameter ALIAS 
MAXIMUM LINKS limits the number of logical links you can initiate 
using the alias node address. The object parameter ALIAS OUTGOING 
identifies the network services that are to use the alias node address for 
outgoing connections, while the object parameter ALIAS INCOMING 
specifies whether certain network services will respond to incoming 
connect requests directed to the alias node address. 

• Files composing the permanent database can now be shared between 
nodes in a VAXcluster. To aid in sharing, the Version 4.3 permanent 
node file NETNODE.DAT will be converted during the VMS Version 
4.4 upgrade to two files: NETNODE_LOCAL.DAT and NETNODE_ 
REMOTE.DAT. This change results in a revision to the procedure for 
converting an existing network to a multiple-area network. 

• Addition of a new Ethernet circuit device, the DELUA, similar in function 
to a DEUNA. 

• Addition of a new DMR11 line parameter, TRANSMIT PIPELINE, which 
provides for more efficient use of satellite links. 

• Addition of VAX PSI support for multiple networks. A VAX PSI system 
can now be configured for more than one DTE and for several network 
connections to several PSDNs. Therefore, for certain configurations, 
references in this manual to your local DTE, network, or PSDN may 
actually apply to multiple DTEs, networks, or PSDNs. New NCP 
parameters identify the network connections for DTEs, destinations, 
circuits and lines. Specifically, the NETWORK/KNOWN NETWORKS 
parameter in the X.25 protocol module command identifies the networks 
to which the DTEs are connected. The NETWORK parameter is used 

in the X.25 server module command to indicate from which network a 
destination will accept calls, and in circuit and line commands to associate 
an X.25 circuit or line with a network. An example of a multinetwork 
configuration appears in this manual. 

• Addition of certain NCP parameters for an X.25 protocol module being 
used with an ISO standard 8208 network. The two parameters used with 
the DTE qualifier in the X.25 protocol module command are INTERRUPT 
TIMER and INTERFACE. The INTERFACE parameter, which indicates 
whether the processor acts as a DTE or DCE, can also be specified for an 
X.25 line. 

• Association of several existing X.25 protocol module parameters with 
particular DTEs. 
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New and Changed Features 



• Addition of the following new NCP parameters to the X.25/X.29 server 
module to identify destinations and support the called address extension 
facility: 

CALLED ADDRESS 
EXTENSION MASK 
INCOMING ADDRESS 
EXTENSION VALUE 
RECEIVING DTE 
REDIRECT REASON 
SENDING ADDRESS 

• Use of VAX PSI for DCE to DTE operations, enabling the X.25 protocol to 
be used for back-to-back operations. 


Deletion of support for the tracing facility with VAX PSI. The 
SET/DEFINE MODULE X25-TRACE command is no longer supported 
except for control of VAX PSI software prior to Version 4.0. 


The VAX/VMS Networking Manual , now a reference manual, was previously 
published as a guide, the Guide to Networking on VAX/VMS, in VAX/VMS 
Version 4.2. 
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1 Overview of DECnet—VAX and VAX PS I 


This chapter presents an overview of the networking software used on 
VAX/VMS systems: what the software is, how to manage it, and how to 
interface with it as a user. The chapter introduces DECnet-VAX software, 
which enables access to the DECnet network, and VAX PSI software, which 
provides access to a packet switching network. The same VAX/VMS network 
management tools are used to manage both DECnet-VAX and VAX PSI. 

The following sections introduce the network terms and concepts that you 
will encounter throughout this manual, identify network software, describe 
network configurations, and provide a brief summary of network management 
responsibilities. The chapter also defines the application user's relationship to 
the network. 

For details about specific topics, you should consult the pertinent chapters 
of this manual, other manuals in the VAX/VMS document set, and VAX PSI 
manuals (see the Preface). 


1.1 General Description of a DECnet Network 

Computer processes communicate with one another over a data network. 

This network consists of two or more computer systems called nodes and the 
logical links between them. A logical link is a connection, at the user level, 
between two processes. Adjacent nodes are connected by physical lines over 
which circuits operate. A circuit is a communications data path over which 
all input and output (I/O) between nodes takes place. A circuit can support 
many concurrent logical links. 

Nodes can also be physically connected to a packet switching data network 
(PSDN) to allow DECnet circuits to be mapped to PSDN virtual circuits. 
Virtual circuits are logical associations between nodes for the exchange 
of data; the actual circuit employed is invisible to the user. Alternatively, 
computers or terminals can be attached directly to a PSDN without using a 
DECnet data link, or can use a connector node as a gateway to communicate 
with remote nodes over a PSDN. 

In a network of more than two nodes, the process of directing a data message 
from a source to a destination node is called routing. DECnet supports 
adaptive routing, which permits messages to be routed through the network 
over the most cost-effective path; messages are rerouted automatically if a 
circuit becomes disabled. 

Nodes can be either routing nodes (called routers) or nonrouting nodes 
(known as end nodes). Both routing nodes and end nodes can send messages 
to and receive messages from other nodes in the network. However, routing 
nodes have the ability to forward or route messages from one node to another 
when the two nodes exchanging these messages have no direct physical link 
between them, except for the path that includes the node forwarding the 
message. End nodes can never have more than one circuit connecting them 
with the network. Any node that has two or more circuits connecting it to 
the network must be a router. 
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Phase IV DECnet supports the configuration of very large, as well as small, 
networks. In a network that is not divided into multiple areas, a maximum 
of 1023 nodes is possible, but the optimum number of nodes is much less 
(approximately 200 to 300 nodes, depending on the topology). Area routing 
techniques permit configuration of very large networks, consisting of up to 63 
areas, each containing a maximum of 1023 nodes. In a multiple-area network, 
nodes are grouped into separate areas, each functioning as a subnetwork. 
DECnet supports routing within each area and a second, higher level of 
routing that links the areas. Nodes that perform routing within a single area 
are referred to as level 1 routers; those that perform routing between areas as 
well as within their own area are called level 2 routers (or area routers). 


1.2 DECnet-VAX and VAX PSI 

DECnet-VAX networking software can be configured on all VAX/VMS 
operating systems and all MicroVMS operating systems. VAX PSI software 
can also be installed and configured on VAX/VMS and MicroVMS systems. 
These software products are identified and described below. 


1.2.1 DECnet Interface with VAX/VMS 

DECnet is the collective name for the software and hardware products 
that are a means for various DIGITAL operating systems to participate in 
a network. DECnet-VAX is the implementation of DECnet that causes 
a VAX/VMS operating system to function as a network node. As the 
VAX/VMS network interface, DECnet-VAX supports both the protocols 
necessary for communicating over the network and the functions necessary 
for configuring, controlling, and monitoring the network. A DECnet-VAX 
node can communicate with other DECnet-VAX nodes in the network or with 
any other DIGITAL operating system that supports DECnet. 

A DECnet multinode network is decentralized; that is, many nodes connected 
to the network can communicate with each other without having to go 
through a central node. As a member of a multinode network, your node can 
communicate with any other network node, not merely the nodes that reside 
next to you, and gain access to software facilities that may not exist on your 
local node. An advantage of this type of network is that it allows different 
applications running on separate nodes to share the facilities of any other 
node. 

Optionally, very large DECnet networks can be divided into multiple areas, 
for the purpose of hierarchical (area) routing. Area routing introduces a 
second, higher level of routing between areas (groups of nodes), which results 
in less routing traffic throughout the network. Each node in a multiple-area 
network can still communicate with all other nodes in the network. 
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1.2.2 VAX Packetnet System Interface 

VAX Packetnet System Interface (PSI) is a software product that allows 
the VAX/VMS user to communicate across PSDNs. VAX PSI implements 
the CCITT X.25 and X.29 recommendations (described in Section 1.3.4), 
providing a user interface to a PSDN. A PSDN consists of switching nodes 
connected by high-speed links, to which computers or terminals can be 
attached. 

You can use VAX PSI in the following ways: 

• To link DECnet nodes across a PSDN through data link mapping (DLM). 
This permits an X.25 virtual circuit to be used as a DECnet data link. 

• To communicate directly across a PSDN to a DIGITAL or non-DIGITAL 
computer over an X.25 virtual circuit. 

• To communicate directly across a PSDN to a character-mode terminal that 
is connected to a packet assembly/disassembly (PAD) device. The PAD 
may be privately owned or located within the PSDN. 

• To communicate by way of a PSDN between terminals on a local VAX PSI 
node and remote DIGITAL or non-DIGITAL computers. VAX PSI contains 
a host-based PAD that provides this capability. 

An alternative version of VAX PSI, called VAX PSI Access, can be used on a 
VAX/VMS node that does not connect directly to a PSDN. VAX PSI Access 
provides all the capabilities of VAX PSI, except that it uses DECnet to connect 
to a VAX PSI node, which in turn connects to a PSDN. The VAX PSI node is 
known as a connector node and the VAX PSI Access node is known as a host 
node. Each connector node can connect to one or more PSDNs, and each 
host node can connect to one or more connector nodes. 

In addition, two VAX/VMS nodes with VAX PSI may communicate with each 
other using the X.25 protocol, but without a PSDN. The nodes are linked by 
a cable or leased line. One node acts as a DTE and the other node as a DCE. 


1.2.3 DECnet Functions 

Networking functions you can perform using DECnet-VAX are listed below. 
These functions are introduced in this chapter and described in detail in later 
chapters of this manual, as indicated. 

• Network management functions 

— Controlling the network (Chapters 2 through 7) 

— Providing DECnet-VAX host services to other DECnet nodes 
(Chapter 4) 

— Performing routing configuration and control (Chapters 2 and 3) 

— Establishing DECnet-VAX configurations (Chapters 2, 3 and 5) 

• Applications user functions 

— Accessing files across the network (Chapters 8 and 9) 

— Using a heterogeneous command terminal (Chapter 8) 

— Performing task-to-task communications across the network 
(Chapter 8) 
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DECnet products are based on the layered network design specified in the 
DIGITAL Network Architecture (DNA). Figure 1-1 illustrates the DECnet 
functions, the various DNA layers at which they are initiated, and the DNA 
protocols by which these functions are implemented. Each DNA layer is a 
client of the next lower layer and does not function independently. For a 
complete description of DNA, see the DNA specifications. The DECnet-VAX 
configurations that use the Ethernet, DDCMP, Cl, and X.25 protocols are 
defined in the following section. 

Figure 1-1 DECnet Functions and Related DNA Layers and 
Protocols 
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1.3 DECnet—VAX Configurations 

DECnet supports the following network connections: 

• A connection to an Ethernet circuit in a local area network configuration 

• A connection to a node running DECnet using the DIGITAL Data 
Communications Message Protocol (DDCMP): either a synchronous 
point-to-point or multipoint connection or an asynchronous static or 
dynamic point-to-point connection 

• A connection over the computer interconnect (Cl) to another node running 
DECnet 

• An X.25 connection to a node running DECnet (either a direct connection 
over a PSDN or a connection made by means of an X.25 multihost 
connector node that accesses a PSDN) 
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Figure 1-2 is a sample DECnet-VAX Phase IV configuration that illustrates 
various kinds of DECnet-VAX nodes (MicroVMS end nodes, VAX/VMS 
routers and end nodes, and VAX/VMS routers in a VAXcluster) connected to 
an Ethernet, and two Ethernets connected by means of routers. The figure 
shows the use of a DDCMP synchronous line to connect a router to additional 
DECnet nodes, and static (permanent) asynchronous DDCMP lines to connect 
MicroVMS end nodes to a router. It also indicates a dialup connection 
between a MicroVMS system and a routing node in the VAXcluster over a 
dynamic asynchronous DDCMP line (switched on for the length of the call). 

The figure demonstrates two kinds of connections to a PSDN: a VAX/VMS 
node connected directly to a PSDN by means of an X.25 circuit, and 
VAX/VMS host nodes connected to a PSDN by means of a VAX/VMS 
connector node that serves as a gateway to the PSDN. DECnet-VAX 
connections are described below. A detailed discussion of the various types 
of circuits and lines used in a DECnet network is presented in Chapter 2. 

Figure 1-2 Sample DECnet-VAX Phase IV Configuration 
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1.3.1 DECnet—VAX Ethernet Local Area Network Configuration 

The Ethernet is a local area network component that provides a reliable high¬ 
speed communications channel, optimized to connect information processing 
equipment in a limited geographic area, such as an office, a building, or a 
complex of buildings (for example, a campus). 
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Local area networks (LANs) are designed for a wide variety of technologies 
and arranged in many configurations. Digital Equipment Corporation, 

Intel Corporation, and Xerox Corporation collaborated in producing the 
Ethernet specification to develop a variety of LAN products. DIGITAL's 
implementation of the Ethernet specification that was originated by the Xerox 
Corporation appears at the lowest two levels of the overall DNA specification: 
the Physical layer and the Data Link layer. 

At the Physical layer, the Ethernet topology is a bus, in the shape of a 
branching tree, and the medium is a shielded coaxial cable that uses 
Manchester-encoded, digital baseband signaling. The maximum data rate 
is 10 million bits per second. Maximum utilization of an Ethernet's data 
transmission capability occurs when multiple pairs of nodes communicate 
simultaneously. In practice, DECnet transmission between a pair of nodes on 
an Ethernet occurs at a considerably lower rate. Each Ethernet can support 
up to 1023 nodes; the maximum possible distance between nodes on the 
Ethernet is 2.8 kilometers (1.74 miles). 

At the Data Link layer, network control for the Ethernet is multiaccess, fairly 
distributed to all nodes. Ethernet access control is CSMA/CD. The frame 
length allocation is from 64 to 1518 bytes (including an 18-byte envelope). 

Ethernet circuit devices supported by DECnet-VAX are the DEUNA and 
DELUA (both known as the UNA) and the DEQNA (called the QNA). The 
VAX/VMS system uses the DEUNA or the DELUA, and the Micro VMS 
system uses the DEQNA. 


1.3.1.1 Ethernet Datagrams 

Message packets sent over Ethernet are called datagrams. Because there is 
no guarantee that a datagram will be received by the intended destinations, 
reliable connections (in the form of virtual circuits) may be provided by 
interposing a protocol between the user and the Ethernet datagram service. 

In DNA, this virtual circuit is provided by the Network Services Protocol 
(NSP) in the End Communication layer. 

Initialization of nodes on Ethernet is based on multicast addressing and the 
use of datagrams. It differs from initialization of nodes on DDCMP circuits in 
that it does not involve guaranteed delivery of routing messages. 


1.3.1.2 Transmission and Reception of Ethernet Packets 

An Ethernet is a single shared network channel, with many nodes demanding 
equal access to it. The technique used to mediate these demands is CSMA 
/CD (Carrier Sense, Multiple Access with Collision Detect). A good 
analogy for this technique is the interaction of people at a social gathering. 

To be polite, one does not speak while someone else is talking; that is, one 
listens before speaking; on the Ethernet, listening to determine whether the 
communication medium is already in use is called carrier sense. Messages 
are said to be initially deferred if they are not sent on the Ethernet because a 
transmission is in progress. 

At a social gathering, anyone may begin to talk once he or she determines 
that no one else is; the ability of any station on the Ethernet to use the 
communication medium is known as multiaccess. If two or more people, 
detecting silence, start to talk at about the same time, they note the fact 
and stop talking (that is, each listens while talking and stops if interfering 
with someone else); the noting of the fact that more than one station is 
transmitting, followed by the cessation of communication, is called collision 
detect. 
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When two or more people at a social event start talking simultaneously, they 
stop talking, wait some random time, and start talking again; on an Ethernet, 
this situation is known as backoff and retransmission , and it is expected that 
a random delay before retransmission will eventually clear the collision 
situation. 

There is a further useful analogy between Ethernet and a social event. When 
one is talking to a group of people, everyone can hear everything said. Some 
of what is said is intended for everyone, some is intended for a subset of 
the group (say, everyone over 21), and some is intended for an individual. 
Stations on an Ethernet can hear every message. Some messages are intended 
for all stations (broadcast address), some are intended for a subset (multicast 
address), and some are intended for individual stations (physical address). 

On an Ethernet, every station can listen to every message, and messages 
can be addressed to their intended recipient(s). These two features greatly 
increase the communications efficiency of a network that uses Ethernet over 
that of a completely connected DDCMP network. 


1.3.1.3 Ethernet Routers and End Nodes 

Ethernet supports connections to routers and end nodes. On an Ethernet, a 
routing node selected as a designated router can perform routing services on 
behalf of end nodes. In addition, routers can route packets between Ethernet 
nodes and non-Ethernet nodes (such as nodes on DDCMP circuits). An end 
node on an Ethernet can communicate directly with any other node (router 
or end node) on the same Ethernet by sending a message directly to the 
addressed node. Note that an end node on a non-Ethernet circuit can only 
communicate with an adjacent node on the same circuit. 


1.3.2 DDCMP Network Configurations 

DDCMP provides a low-level communications path between systems. The 
DDCMP protocol performs the basic communications function of moving 
information blocks over an unreliable communication channel. (The protocol 
detects any bit errors introduced by the channel and requests retransmission 
of the block.) DDCMP is also used to manage the orderly transmission and 
reception of blocks on channels with one or more transmitters and receivers. 

The DDCMP protocol is supported on synchronous and asynchronous 
communications devices. DDCMP connections can be point-to-point or 
multipoint configurations. Point-to-point connections are either synchronous 
or asynchronous. The two types of asynchronous connections are static 
(permanent) and dynamic (switched temporary). Multipoint connections are 
always synchronous. These connections are described below. 


1.3.2.1 DDCMP Point-to-Point and Multipoint Connections 

Figure 1-3 illustrates DDCMP point-to-point and multipoint configurations. 

A point-to-point configuration consists of two systems connected by a single 
communication channel. 

A multipoint configuration consists of two or more systems connected by a 
communications channel, with one of the systems (called the control station) 
controlling the channel. All other systems on the communications channel 
are known as tributaries. (Note that if only two systems are connected in a 
multipoint configuration, one is the master and one is the tributary. However, 
this is not a very efficient use of the communication channel.) The control 
station is responsible for telling the tributaries, in turn, when they may use 
the channel; this procedure is known as polling. Tributaries are not allowed 
to use the channel until they are polled. The control station, however, may 
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use the channel whenever it is available. Also, the tributaries on a multipoint 
line are not allowed to communicate directly with each other, but only 
through the master. 

Figure 1-3 Typical DDCMP Point-to-Point and Multipoint 
Connections 
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Point-to-point circuits and multipoint circuits perform as virtual circuits: 
nodes on these circuits interact as though a specific circuit were dedicated 
to them throughout the transmission; in fact, however, the actual physical 
connection is allocated by the routing mechanism. Initialization of nodes 
on DDCMP circuits involves guaranteed delivery of routing messages. Also, 
individual nodes on DDCMP circuits must be addressed directly; no multicast 
or broadcast addressing capability is available as with an Ethernet circuit. 


1.3.2.2 Synchronous DDCMP Connections 

Synchronous communications devices are used for high-speed point-to-point 
or multipoint communication (for example, connecting two VAX-11/780 
systems). 

The synchronous DDCMP protocol can run in full- or half-duplex operation. 
This allows DDCMP the flexibility of being used for local synchronous 
communications, or for remote synchronous communications over a telephone 
line using a modem. DDCMP has been implemented in microcode in such 
devices as the DMC11 and DMR11 to run at speeds up to one megabit per 
second in a point-to-point configuration. The DDCMP multipoint protocol 
(point-to-point also) has been implemented in microcode in the DMP11 
device to run at speeds up to 500 kilobits per second. For the DMF32, 
DDCMP has been implemented in the driver software for the synchronous 
communications port. 


1.3.2.3 Asynchronous DDCMP Connections 

Asynchronous connections provide for low-speed, low-cost, point-to- 
point communication (for example, as an inexpensive way of connecting 
a Micro VAX system to a VAX-11/780 system). Asynchronous DDCMP 
is implemented in software and can be run over any terminal line that 
VAX/VMS supports. The asynchronous DDCMP protocol provides for a full- 
duplex connection and can be used for local asynchronous communications 
or for remote asynchronous communications over a telephone line using 
a modem. Asynchronous connections are not supported for maintenance 
operations or for controller loopback testing. 

Two kinds of asynchronous connections can be made over the network: 

• A static connection: the asynchronous line is permanently configured as a 
communications device 
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• A dynamic connection: a line connected to a terminal port is switched to 
an asynchronous communications line for the duration of a call 


1.3.2.4 Static Asynchronous Connections 

A static asynchronous DDCMP connection is a permanent DECnet connection 
between two nodes (for example, a Micro VMS node and a VAX/VMS node) 
physically connected by terminal lines. The terminal lines are converted 
to static asynchronous DDCMP lines by issuing commands to set the lines 
to support the DDCMP protocol. The user at each node then turns the 
appropriate circuits and lines on for DECnet use. Once the communications 
link is established, it remains available until a user turns off the circuit and 
line and clears the entries from the DECnet database. 

Static asynchronous DDCMP configurations require that the asynchronous 
DDCMP driver be connected. The asynchronous DDCMP protocol can 
run in full-duplex operation on local asynchronous communication devices. 
Examples of these devices are the DZ11 and the DMF32 asynchronous 
communications port. 

The user can configure a dialup line as either a static or dynamic 
asynchronous line, but may find the dynamic connection more secure and 
convenient to use. 


1.3.2.5 Dynamic Asynchronous Connections 

A dynamic asynchronous connection is a temporary connection between two 
nodes, generally over a telephone line using modems. The terminal lines 
at both ends of the connection can be switched to asynchronous DDCMP 
communications lines and then switched back to terminal lines. 

You can use dynamic asynchronous connections to establish a DECnet link to 
another computer for a limited time or to create links to different computers 
at different times. 

For example, as a Micro VMS system user, you can cause a dynamic 
asynchronous connection to be made for the length of the telephone call 
to a VAX-11/780 system. You must first establish your system as a terminal 
emulator (enabling the processor to perform as though it were a terminal 
line). You dial in over a telephone line to the other system (which is 
established as a virtual terminal) and log in. You can then issue a command 
which causes the terminal lines at each end of the connection to be switched 
to asynchronous lines for DECnet use. When you hang up or turn the circuit 
off, the lines are automatically switched back to terminal lines. 

Security measures provide protection against a caller at an unauthorized 
node being able to form a dynamic asynchronous connection with another 
node (see Section 2.10.6). Before a dialup node can establish a dynamic 
connection with a remote node, the remote node verifies that the dialup 
node is authorized to make a connection. It checks that the node is of 
the appropriate type (router or end node), and, without revealing its own 
password, verifies the routing initialization password sent by the dialup node. 
Also, for increased security, the connection will be ended automatically when 
the telephone is hung up. 

A dynamic asynchronous connection can also be established over a hardwired 
terminal line. The connection is maintained for the duration of the DECnet 
session. The dynamic connection permits the system to be used as a terminal 
emulator when not switched to DECnet use. 
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1.3.3 DECnet—VAX Configurations for VAXciusters 

A VAXcluster is an organization of VAX/VMS systems that communicate over 
a high-speed communications path, the Cl, and share processor resources 
as well as disk storage. Figure 1-4 shows a typical VAXcluster. The Cl is 
the physical link between the nodes in a VAXcluster. Cl cables from the 
individual nodes in the cluster are connected to a star coupler. The HSCs are 
hierarchical storage controllers that enable VAXcluster nodes to share disks. 

Figure 1-4 Typical VAXcluster Configuration Using Cl as a Data 
Link 
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DECnet-VAX connections are required for all VAX/VMS systems in the 
VAXcluster. Use of DECnet-VAX ensures that VAXcluster system managers 
can access each node in the cluster from a single terminal, even if terminal¬ 
switching facilities are not available. DECnet-VAX is also required by the 
User Environmental Test Program (UETP). 

The choices for DECnet-VAX physical links for use in the VAXcluster are 

• Connecting each VAX/VMS node in the cluster to an Ethernet (as shown 
in Figure 1-2) 

• Using the Cl that connects the cluster nodes as the DECnet-VAX data link 
(as shown in Figure 1-4) 

Connecting each VAXcluster node to an Ethernet provides distinct advantages: 


• Each node in the cluster can be an end node, resulting in lower overhead 
for these nodes, decreased routing traffic throughout the network, and 
simpler installation procedures. Note that there must be at least one 
router on the Ethernet to which the cluster end nodes are attached. 

• Ethernet provides for better performance in DECnet transmissions than 
the Cl, despite the higher data link bandwidth of the Cl, because the 
Ethernet communications protocol allows larger buffer sizes. 
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• Terminal servers can be used when nodes in a VAXcluster are connected to 
an Ethernet. DIGITAL's terminal servers offer a number of benefits to the 
VAXcluster user, such as load balancing and easier cluster management. 


If only one physical link is used to connect each cluster node to the network, 
the Ethernet link should be used instead of the Cl data link, because of 
the better DECnet performance of the Ethernet. In this case, the Cl should 
perform the functions of a system bus and not be enabled as a DECnet data 
link. 

A VAXcluster node connected to an Ethernet may require additional DECnet 
links in order to communicate with remote nodes not on the Ethernet. A 
VAXcluster node connected to more than one DECnet link must be configured 
as a router, not an end node. 

If the nodes in the VAXcluster are not connected to an Ethernet, the Cl should 
be used as the DECnet data link between the nodes. Cl circuit devices are 
configured as though they were multipoint devices, but each node on the Cl 
can talk directly to every other node and no polling is involved. 

A two-node VAXcluster that uses the Cl as the data link can be configured 
using end nodes. If additional nodes are configured in the cluster, however, 
at least one router is required. The Cl does not have a broadcast capability 
(such as that of the Ethernet). Thus, the router is needed so that the nodes 
in the cluster can identify each other. If the router in a three-node cluster 
fails, the cluster reverts to being a two-node cluster and can consist of end 
nodes only. Network management commands can be used to create a circuit 
between the end nodes. For a cluster of four or more nodes, more than one 
router is required in order to prevent the loss of communications capability 
between the remaining nodes if one router fails. Also, backup circuits can be 
provided between end nodes in case of router failure. 

A VAXcluster can be configured so that the whole cluster appears to other 
network nodes as though it were a single node, with an address different from 
that of any DECnet node within the VAXcluster. This address usually has a 
node name associated with it. Thus it is possible to access the VAXcluster 
as a whole by an alias node identifier, which can be either its node name 
or its node address. All or some of the nodes in a VAXcluster can elect 
to use this special node identifier as an alias, while retaining their unique 
individual node names and addresses. Each node that assumes the alias node 
identifier can specify whether it will accept incoming connections directed 
to the alias address. It can also specify the network services for which the 
cluster alias node identifier is to be used on outgoing connections and the 
network services that will accept incoming calls. 

At least one of the nodes in the cluster that accepts the alias node identifier 
must be a router. The router informs other nodes in the network of the alias 
node address for the cluster. When the router receives packets addressed 
to the alias node address, it forwards them to the appropriate nodes in the 
cluster. The cluster alias node identifier can be very useful in network 
operations involving shareable resources. Network users outside the 
VAXcluster can access cluster resources without knowing which nodes are 
active in the cluster. For example, if a user on a cluster node sends a MAIL 
message, it does not matter whether that particular node is active when a 
reply to the message is received. 
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1.3.4 X.25 Network Configurations 

Packet switching data networks provide fast, dependable communications 
between geographically distributed nodes. Data transmitted over a PSDN 
is divided into packets, each of which has a header containing control and 
destination information. The PSDN interleaves packets from many users over 
shared transmission lines and delivers the packets in the correct order to the 
proper destinations. The routing of packets through the PSDN is handled by 
the PSDN itself and is invisible to the user. 

In X.25 network terminology, your computer or terminal is called data 
terminal equipment (DTE) and the PSDN interface to which it is connected 
is known as data circuit-terminating equipment (DCE). The DTE can 
operate in packet mode or in character mode. A character-mode terminal is 
also known as an X.29 terminal. 


1.3.4.1 X.25 and X.29 Recommendations 

Recommendations for standard network interfaces for DTEs have been 
established by the CCITT (Comite Consultatif International Telegraphique 
et Telephonique). The X.25 recommendation defines the interface between 
the packet-mode DTE and the DCE. The X.25 recommendation defines 
three levels of protocols for this interface: Level 1 covers physical and 
electrical characteristics; Level 2, link access procedures; and Level 3, packet 
procedures. 

The X.29 recommendation defines the procedures for information exchange 
between a packet-mode DTE (an asynchronous terminal) and the packet 
assembly/disassembly (PAD) facility of the PSDN or host. 

Communication between a local DTE and a remote DTE is by means of a X.25 
virtual circuit, a logical association between the two DTEs set up specifically 
to handle the exchange of data between them. An X.25 virtual circuit can 
be permanent or temporary. The permanent virtual circuit (PVC) is similar 
to a leased line. The temporary or switched virtual circuit (SVC) is similar 
to a dialup line and requires that calls be set up and cleared. A local DTE is 
connected to the PSDN by a synchronous X.25 line, over which X.25 virtual 
circuits operate. Examples of X.25 line interfaces are the DUP11 and the 
DMF32 synchronous line unit. 

As well as supporting various PSDNs, VAX PSI can also support an ISO 
standard 8208 network. IS 8208 is the International Standards Organization's 
definition of the CCITT X.25 recommendations. 

Note that a single VAX PSI system can support several DTEs. These may 
either be connected to different PSDNs or provide different routes to the 
same PSDN. 


1.3.4.2 X.25 Connections 

Figure 1-5 illustrates typical X.25 connections that permit a VAX/VMS node 
to communicate with a remote node over a PSDN. A VAX/VMS node can be 
configured to communicate over a PSDN in the following ways: 
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Figure 1-5 X.25 Connections in a DECnet Network 
Configuration 



• By means of a data link mapping (DLM) circuit, an X.25 virtual circuit 
used as a DECnet data link (provided the remote node runs PSI and 
DECnet-VAX or DECnet-RSX) 

• Through a direct connection to a PSDN over an X.25 virtual circuit (this is 
called native-mode operation) 

• As a host node using a VAX/VMS multihost connector node to access a 
PSDN 

You must have VAX PSI software installed on your DECnet-VAX node to 
configure your node for VAX PSI native-mode operation or multihost-mode 
operation. Native-mode operation permits incoming and outgoing calls to be 
made between the local node and a remote DTE. Multihost-mode operation 
allows the local node to be a connector node or gateway, which host nodes 
can use to communicate over a PSDN with remote DTEs. Each host node 
must have VAX PSI Access software installed. 

Alternatively, a VAX/VMS node with VAX PSI Access software installed can 
access a PSDN by means of an Ethernet communications server, the DECnet 
Router/X.25 Gateway. 


1.4 Managing the Network 

As system manager of a VAX/VMS operating system, you can use a network 
management utility program to configure the system as a DECnet-VAX node 
in the network, and perform network management and maintenance functions 
for your own node and other nodes in the network. This section summarizes 
network management functions. 
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1.4.1 Network Control Program 

To configure, control, monitor, and test the network, use the Network Control 

Program (NCP), a VAX/VMS utility program. The types of users who employ 

NCP are 

• Users of both DECnet-VAX and VAX PSI. These users can employ all 
NCP commands. 

• Users of DECnet-VAX only. DECnet-VAX users employ all NCP 
commands except those that relate to X.25 modules. 

• Users of VAX PSI only. PSI native-mode and multi-host-mode users (who 
are not using DECnet-VAX circuits) employ only NCP commands that 
relate to X.25 modules, circuits, lines, objects, and logging. 


The network components the system manager configures are listed in 
Section 1.4.5.3 and described in detail in Chapter 2. The use of NCP 
commands and parameters to perform network management is discussed 
in Chapter 3. The NCP commands and parameters and guidelines for using 
them, including restrictions on the use of individual NCP parameters, are 
specified in the VAX/VMS Network Control Program Reference Manual. 


1.4.2 Network Management Responsibilities 

As system manager of a DECnet-VAX network, you have a number of key 

responsibilities, which include: 

• Defining network components and their parameters in a central 
configuration database at the local node and, optionally, at remote 
nodes. (The local node is the node at which you are physically located; a 
remote node is any node other than the local node in your network.) 

• Coordinating with the system managers of other nodes in the network 
to ensure uniform assumptions about network parameter settings such as 
circuit cost. 

• Configuring your node to ensure proper network routing operation and 
updating VAX/VMS SYSGEN procedures to allow enough space for the 
networking software. 

• Controlling and monitoring local and remote network operation. 

• Testing network hardware and software operation. 

• Loading systems downline to unattended remote nodes. 

• Connecting to an unattended remote node to serve as its console. 

If your network includes VAX PSI, you have the following additional 

responsibilities: 

• Defining VAX PSI components and their parameters in the network 
configuration database and thus configuring VAX PSI. 

• Monitoring the operation of VAX PSI using PSI management utilities. 

• Analyzing hardware and software operation and diagnosing problems 
related to PSI operation. 
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The following sections outline the network-related tasks that you perform as 
system manager and describes several of the facilities DECnet-VAX and VAX 
PSI provide to perform those tasks. 


1.4.3 DECnet—VAX Licenses 

Licenses are available for either a DECnet-VAX full function kit or a DECnet- 
VAX end node kit. If you have purchased either license, you must install the 
key for the license to enable inter-node communication. The procedure for 
installing the appropriate license key is described in the DECnet-VAX Key 
Installation Guide , distributed with the key. 

If you have purchased a license for a DECnet-VAX end node kit and now 
require the additional capabilities of the DECnet-VAX full function license, 
you can purchase a DECnet-VAX license that upgrades the end node license 
to a full function license. This upgrading license is applicable to all DECnet- 
VAX nodes. The full function kit contains the material to implement this 
upgrade. 

The DECnet-VAX full function kit allows the node on which it has been 
installed to be configured as either a routing node or an end node. The end 
node kit allows the node to be configured only as an end node. 


1.4.4 DECNET-VAX and VAX PSI Network Management Software 

Figure 1-6 displays the DECnet-VAX and VAX PSI software that the system 
manager uses to configure, control, and monitor the network. 

Figure 1-6 DECnet-VAX and VAX PSI Software 



Network management software components are described below. 

• Ethernet configurator (NICONFIG). NICONFIG is a network image 
that listens to system identification messages on Ethernet circuits, and 
maintains a user-accessible database of configuration information on all 
systems on the Ethernet. 
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• Event logger (EVL). EVL is an image that logs significant events to 
provide information to the system manager for possible intervention or 
future reference. 

• File access listener (FAL). FAL is a network image that receives and 
processes remote file access requests for files at its node on behalf of 
remote users. 

• Host loader (HLD). HLD is an image that communicates with the DECnet- 
RSX Satellite Loader (SLD) to load tasks downline to an RSX-11S node. 

• Loopback mirror (MIRROR). MIRROR is a network image that participates 
in Network Service Protocol (NSP) and Routing layer loopback testing. 

• Network ancillary control process (NETACP). NETACP is a VAX/VMS 
ancillary control process that controls all lines and circuits, maintains a 
picture of the network topology, and creates a process to receive inbound 
logical link connection requests. 

• Network Control Program (NCP). NCP is an interactive utility program 
that permits you to control and monitor the network. 

• Network driver (NETDRIVER). NETDRIVER is a VAX/VMS pseudo¬ 
device driver that provides logical link and routing services. It implements 
NSP and Routing, and provides a user process with a Queue I/O (QIO) 
interface to a logical link service. 

• Network management listener (NML). NML is an image that receives 
network management commands, such as NCP commands, from the 
Network Management layer through the Network Information and Control 
Exchange (NICE) protocol. NML performs all local network management 
functions as well as control and information functions requested by remote 
nodes. NML spawns a subprocess, the maintenance operation module 
(MOM), for maintenance functions such as downline load, upline dump, 
and loopback testing. 

• PSI ancillary control process (PSIACP). PSIACP is a VAX/VMS ancillary 
control process that controls all X.25-related functions. It is present only if 
VAX PSI is started. PSIACP has the VAX PSI volatile database. 

• Permanent database. The permanent database is a collection of disk- 
resident files that define the network as known to the local node. If VAX 
PSI is configured in the network, a subset of the permanent database is 
maintained as the VAX PSI permanent database for the local DTE(s). 

• Volatile database. The volatile database, maintained by NETACP, is 
a memory-resident database containing current network configuration 
parameters. If VAX PSI is configured in the network, a subset of the 
volatile database is maintained as the PSI volatile database in PSIACP for 
the local DTE(s). 

Many of these software components are user-transparent processes over 
which the system manager has no control. This manual describes DECnet- 
VAX and VAX PSI software only as it serves to highlight and clarify the 
functions and operation of NCP. The various DNA specifications describe the 
different protocols that facilitate network communication. 
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1.4.5 Configuring a Network 

The system manager must configure each DECnet-VAX node and VAX PSI 
DTE as part of the network. 


1.4.5.1 Configuring a DECnet-VAX Node 

At the outset, the system manager is responsible for configuring the network 
from the perspective of local node network operation. This involves 
supplying information at the local node about various network components 
such as nodes, circuits, lines, and objects. This information constitutes what 
is called the configuration database for the local node. Each node in the 
network has such a database. You supply information about the configuration 
database through NCP. 

If you are configuring a DECnet-VAX node for the first time or wish 
to rebuild the configuration database for your local node, you can use 
the interactive NETCONFIG.COM procedure to configure your node 
automatically. To update an existing node database to contain current 
information about other nodes in the network, you can copy the information 
from the node database of another node to which you have access. 

Chapter 3 discusses the function of the configuration database and the general 
use of NCP and most NCP commands. Chapter 5 describes the use of the 
NETCONFIG.COM procedure to configure your node automatically, and 
presents sample configuration commands for various network configurations. 
The VAX/VMS Network Control Program Reference Manual contains a summary 
description of NCP operation, command prompting, and the syntax of all 
NCP commands. 


1.4.5.2 Configuring VAX PSI DTEs 

If VAX PSI is to be run, the system manager is responsible for installing 
and configuring VAX PSI for the local DTEs. Configuring VAX PSI involves 
supplying information about various VAX PSI components, such as circuits, 
lines, modules, and objects. The information is contained in the PSI 
configuration database for the local DTE and, if both DECnet-VAX and VAX 
PSI are configured, in the DECnet-VAX configuration database for the local 
node. You use NCP commands to supply information to the configuration 
database. 

If your node is to serve as an X.25 multihost connector node to provide access 
to PSDNs for host nodes, you must configure VAX PSI software in multihost 
mode. If your node is to be a host node that uses the multihost connector 
node to access a PSDN, you need to install and configure only the VAX PSI 
Access software. The procedures for configuring VAX PSI software or VAX 
PSI Access software on your DECnet-VAX node are described in Chapter 5. 


1.4.5.3 A Network Topology 

Figure 1-7 illustrates a hypothetical network topology made up of various 
DIGITAL operating systems. Figure 1-8 illustrates the same topology for 
a network that has been divided into multiple areas. These examples are 
referred to as the "network examples" throughout this manual. 
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Figure 1-7 Topology of a Single-Area DECnet Network 


DENVER 

( 1 . 14 ) 

VAX/VMS 



Physical line 


( 1 . 17 ) 


-Circuit 


RSX-11S 


ZK-1863-84 


1-18 

































Overview of DECnet-VAX and VAX PSI 


Figure 1-8 Topology of a Multiple-Area DECnet Network 
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Figures 1-7 and 1-8 show some, but not all, of the network components 
about which the system manager gathers and consolidates information in the 
configuration database. The six network components that you can control 
using NCP are described below. 

• Nodes. Nodes are DIGITAL operating systems using DECnet software to 
communicate with other operating systems across the network. 

• Modules. VAX PSI modules include the X.25 protocol module, which 
performs data packet handling and multiplexing of X.25 circuits over 
lines to PDSNs; and the X.25 and X.29 server modules, which handle 
X.25 and X.29 calls, respectively. DECnet-VAX modules include the X.25 
access module, which permits a VAX/VMS host node to communicate 
over a PSDN by means of a connector node, and the Ethernet configurator 
module, which lists all nodes on the Ethernet. 
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• Circuits. Circuits are virtual communications paths between nodes and 
between DTEs. Circuits operate over physical lines and are the medium 
on which all I/O occurs. DECnet processes "talk" over circuits by means 
of logical links. These links carry a single stream of full-duplex traffic 
between two user-level processes. There can be multiple logical links on 
each DECnet circuit. 

• Lines. Lines are physical data paths between nodes, or between DTEs and 
DCEs (X.25 network interfaces). 

• Objects. Objects are processes that receive logical link requests. They 
perform specific network functions. An example is FAL, which is used for 
remote file access. Objects also receive incoming X.25 calls. 

• Logging. Logging is a network feature that enables the automatic 
recording of useful network events that occur during network operation. 

These components, the DECnet and PSI software modules and databases, and 
the hardware make up the network. NCP command examples in this manual 
relate to the components illustrated in the network example. 


1.5 User Interface to the Network 

This section describes the user interface to the DECnet-VAX network. It 
includes a general description of operations that you can perform over 
the network and a list of the programming languages that you can use 
for designing network applications. This section also presents general 
information that you need to know to access the DECnet-VAX network. 


1.5.1 Performing Network Operations 

You can use the DECnet-VAX software to perform a variety of operations 
over the network. For example, you can 

• Manipulate files on remote nodes (for example, transfer, delete, or rename 
files) 

• Access remote files at the record level 

• Perform task-to-task communications 


DECnet-VAX allows you to access files on remote nodes as though they 
were on your local node. It also allows you to design applications that 
communicate with each other over the network. For detailed information 
on remote file access and task-to-task communication, including examples of 
each type of network application, see Chapter 8. 

Throughout this document, the term task refers to an image running in the 
context of a process, the term local refers to the node at which you are located 
physically, and the term remote refers to that node with which you establish 
a connection. Note that in certain situations such as testing, a logical link can 
be established between two processes on the same node. 

The VAX/VMS operating system and DECnet-VAX communications software 
are integrated to provide a high degree of transparency for user operations. 
For some applications, however, it is desirable (and sometimes necessary) to 
have more direct access to network-specific information and operations. For 
this purpose, DECnet-VAX provides nontransparent communication. 
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The following sections describe some of the general transparent and 
nontransparent features of DECnet-VAX in terms of the user interface to the 
network. For more detailed information, including examples of transparent 
and nontransparent DECnet-VAX applications, see Chapter 8. 

In addition to remote file access and task-to-task communication, DECnet- 
VAX also allows you to communicate with remote nodes through the 
heterogeneous command terminal facility (SET HOST). This feature is 
described in Chapter 8. 

When designing user applications to perform network operations, you can use 
standard DCL commands, higher-level language I/O statements, VAX RMS 
service calls, and system service calls. 


1.5.1.1 Designing User Applications for Network Operations 

DECnet-VAX supports several programming languages for network 
applications: 

• DCL commands and command procedures 

• Higher-level language programs 

• MACRO programs using RMS service calls or system service calls 


You can use several higher-level languages to develop networking 
applications, including VAX Ada, VAX FORTRAN, VAX BASIC, VAX 
BLISS, VAX PASCAL, VAX C, VAX PL/I, and VAX COBOL. With any of 
these languages, you can access remote files and create tasks that exchange 
information across the network. 

Table 1-1 summarizes the normal use of the programming languages for 
specific network operations that you can perform with DECnet-VAX. 


Table 1-1 Network Access Levels 


User Language 

Network Operation 

Language Calls 

Access Level 

DCL 

Network command 
terminals 

Remote file 
manipulation 

Task-to-task 

communication 

DCL commands 

Transparent network access using 
DCL 

Higher-level 

languages 

Remote file access 
(files and records) 

Higher-level 

language 

I/O statements 



Task-to-task 

communication 


Transparent network access using 
RMS 

MACRO or 
higher-level 
languages 

Remote file access 
(files and records) 

Task-to-task 

communication 

RMS service 
calls 


MACRO or 
higher-level 
languages 

Task-to-task 

communication 

System service 
calls 

Transparent and nontransparent 
network access using QIO 


1-21 












Overview of DECnet-VAX and VAX PSI 


1.5.1.2 Choosing a Language for a Specific Network Application 

The way you access the network is directly related to the language you use 
and the network operation you perform. For example, you may want to use 
standard VAX RMS calls in a VAX MACRO program to access remote files, 
then use system service calls to communicate between MACRO programs 
in a task-to-task communication application. Figure 1-9 shows three access 
levels and the corresponding network operations. The various levels of 
network access provide a convenient context in which to discuss typical user 
operations over the network. 

Figure 1-9 Network Access Levels and DECnet-VAX User 
Interface 
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The first two levels of access, DCL and RMS, are entirely transparent to the 
network user. Because you use standard DCL commands and RMS service 
calls to access remote files, no DECnet-specific calls are required at these 
levels of access. You need only specify in your file specification the remote 
node on which the file resides. Likewise, higher-level language tasks can use 
a variation of the standard VAX/VMS file specification in conjunction with 
standard I/O statements to access remote tasks and exchange information; 
thus, this form of task-to-task communication is also transparent. As with 
device-independent input/output (I/O) operations, transparent network 
access allows you to move data across the network with little concern for the 
way this operation is performed. 

The third level of access, system services, provides both a transparent and 
a nontransparent user interface to the network. Transparent communication 
at the system-service level provides all the basic functions necessary for 
two tasks to exchange messages over the network. As with the higher-level 
language I/O interface, these operations are transparent because they do 
not require DECnet-specific calls. Rather, you use standard system service 
calls to implement them. Nontransparent communication extends this 
basic set of functions to allow a nontransparent task to receive multiple 
inbound connections and to use additional network protocol features such as 
optional user data and interrupt messages. As with device-dependent I/O, 
nontransparent communication allows you to exploit certain network-specific 
characteristics to coordinate a more controlled communication environment 
for exchanging information. 


1.5.2 Accessing the Network 

This section presents general information that you need to know to access the 
network via DECnet-VAX software. This information covers network file and 
task specifications, access control parameters, and the use of logical names in 
network applications. 

The format for file specifications is applicable to file-handling operations for 
both the DCL and the RMS interfaces to the network. The task specification 
format pertains to task-to-task communication. The information on access 
control is significant because it defines the way that both local and remote 
nodes grant access to their system resources. 


1.5.2.1 Using File and Task Specifications in Network Applications 

DECnet-VAX uses the standard VAX/VMS file specification format for remote 
file-handling applications. A node specification string that includes a node 
name must be present. You can also include an optional access control string 
in the node specification to specify explicitly the user name and password of 
a specific account to use on the remote system. 

For example, the file specification 

TRNTO"SMITH JOHN"::W0RK_DISK:TEST.DAT;1 

contains explicit access control information and can be used to access the file 
TEST.DAT, which resides in user Smith's top-level directory on the device 
WORK—DISK on node TRNTO. 

The following file specification, which does not contain explicit access control 
information, can also be used to access the remote file TEST.DAT provided 
that a proxy or default nonprivileged DECnet account exists on the target 
node: 

TRNTO::DBA1:[SMITH]TEST.DAT;1 
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For more information on file specification strings, including format examples, 
see the VAX/VMS DCL Concepts Manual. 

Task-to-task communication requires the use of a task specification string 
enclosed in quotation marks. This string identifies the target task to which 
you want to connect on a remote node. For example, the following task 
specification string 

BOSTON: : ,, TASK=TEST2 ,, 

identifies the task TEST2 by means of the TASK= form of task specification. 
You can also use the 0= form to specify a task. For example, 

BOSTON"JONES KC"::"0=TEST2" 

also identifies the task TEST2. Note that in this case, explicit access control 
information is also included in the node specification string. For more 
information on task specifications, see Chapter 8. 


1.5.2.2 Using Access Control for Network Applications 

Access control is the control that a node exercises over inbound logical link 
connections. The terms inbound and outbound refer to the direction of 
the logical link connection request. A node receives and processes inbound 
requests; it processes and sends outbound requests. This distinction is useful 
for discussing access control as it relates to VAX/VMS nodes in a network. 
Refer to appropriate DECnet documentation if the node to which you want to 
connect is not a VAX/VMS system. 

When DECnet-VAX software sends an outbound connection request in 
response to either a remote file access or a task-to-task communication 
operation, certain access control information may be necessary to connect 
successfully to the remote node and log in. As in logging in at your local 
VAX/VMS node, you can supply specific access control information in 
the form of a user name and password that the remote node recognizes. 

The remote node processes inbound connection requests containing 
this information to verify that you are a valid user of the system. For 
more information on inbound and outbound connection requests, see 
Section 2.10.2. 

Figure 1-10 illustrates the access control processing that takes place for a 
simple DCL command. 

When explicit access control information is not provided in the connection 
request, DECnet-VAX software uses the remote node name specified in 
the connection request as a key to locate the appropriate record in the 
local configuration database. This record contains default access control 
information applicable to the remote node. Your system manager creates this 
entry when establishing the configuration database. (Refer to Chapter 3 for 
additional information on the configuration database.) 

Depending on the privileges required by the object to which you want to 
connect and those of the user process (see Figure 1-11), one of three possible 
sets of default access control information is sent to the remote node: default 
privileged, default nonprivileged, or null. Because these defaults are node 
parameters, all privileged operations requested with default access control 
for a given node run under the same default account. The same is true for 
nonprivileged operations requested with default access control. 

If the target node is running DECnet-VAX, it can associate incoming connect 
requests with specific accounts other than the default nonprivileged DECnet 
account. This type of access is known as proxy login and requires that 
the originator of the request have a proxy account on the target node and 
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Figure 1-10 Remote File Access Using Access Control String 
Information 
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that proxy login access be enabled at that node. Proxy login is described in 
Section 2.10.5. 

Figure 1-11 illustrates the access control processing that takes place for the 
same DCL command as in the example in Figure 1-10, except that the DCL 
command does not specify an access control string. 


1.5.2.3 Using Logical Names in Network Applications 

The use of logical names for network operations allows you to refer to 
network file and task specifications without using actual names that you give 
these elements. Logical names serve as a kind of shorthand for specifying all 
or a portion of a full file specification. By using logical names, you can pass 
file specifications defined at the DCL level to an executing image at run time. 
For example, logical names allow a program to access local or remote files 
without changing the program. You can also use logical names to conceal 
access control information from other users by embedding it in a logical name 
defined in the process logical name table. Logical names provide convenient 
and powerful multilevel access control specification. 
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Figure 1-11 Remote File Access Using Default Access Control 
Information 



The rules that govern the use of logical names for network operations are as 

follows: 

• Both the device name and node name in a full file specification string 
can be logical names. However, once a node specification is encountered 
during file parsing, a device name that follows is not translated locally. 
Instead, it is passed unaltered to the remote node, where it is subject to 
logical name translation. 

• A logical name appearing in the device name position in a file specification 
can supply any file specification string elements when translated. 

• A logical name appearing in the node name position can supply only a 
node-spec when translated. Therefore, its equivalence string must end 
with a double colon. 

• An access control string associated with a logical node name becomes the 
new access control string for the node-spec of the equivalence string, even 
if the node-spec contained an access control string. Thus, you can easily 
specify a default (or override any) access control string defined for the 
node-spec resulting from logical name translation. 

• After a logical node name is translated, the new node name becomes a 
candidate for logical node name translation. 
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• A maximum of ten logical device name translations and ten logical 
node name translations is permitted. If you exceed these limits, an error 
message is returned. 

For more information on logical names, including examples of logical names 
that can be used for network applications, see the VAX/VMS DCL Concepts 
Manual. 
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DECnet-VAX Components and Concepts 


This chapter presents networking concepts relevant to understanding the 
operatioji pf Jthe .DECnet network, in terms of the functions performed by 
DECnet-VAX components and VAX PSI components. 

To establish your VAX/VMS operating system as part of the DECnet network, 
you must build and maintain a network configuration database, consisting of 
records that describe the specific network components your particular system 
requires. This chapter describes the DECnet-VAX components and their 
characteristics: nodes, circuits, lines, routing, logical links, objects, logging, 
and network access control. It also describes VAX PSI components used 
in communicating over a packet switching data network (PSDN): the X.25 
protocol module, X.25/X.29 server modules, and X.25 access module. 

Chapter 3 discusses how you can use a DECnet-VAX utility program, the 
Network Control Program (NCP), to enter in your configuration database 
specific parameters for each network component your system will use. 


2.1 Nodes and DTEs 

A node is an operating system that uses DECnet software to communicate 
with other operating systems across a network. A VAX/VMS node uses 
DECnet-VAX software to communicate with other DECnet-VAX nodes and 
with any other DIGITAL operating system that supports DECnet. 

The X.25 equivalent of a node is a DTE (data terminal equipment). A DTE 
is a computer or terminal that uses VAX PSI software to communicate with 
remote nodes across a PSDN. You can configure your DECnet-VAX node as a 
DTE if VAX PSI software is installed on your node. 

Note: A single VAX PSI system can now support several DTEs. (The limit is 
the physical communications capability of the system.) 

A DECnet-VAX node can also be an X.25 connector node, serving as a 
gateway that permits DECnet-VAX host nodes on an Ethernet to access one 
or more PSDNs. To configure your DECnet-VAX node as a connector node, 
you must have VAX PSI software in multihost mode installed. To configure 
your DECnet-VAX node as an X.25 host node, you must have VAX PSI 
Access software installed. 

This section describes the characteristics of nodes and the kinds of parameters 
you can associate with them. It also describes DTEs and indicates how you 
use X.25 protocol modules to define DTEs and the parameters related to them. 
Chapter 3 discusses the use of NCP commands to establish the parameters 
for nodes and DTEs. 
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2.1.1 Nodes 


The VAX/VMS operating system at which you are physically located is called 
the local node. By issuing network management commands at your local 
node, you can perform configuration, control, and monitoring functions that 
affect both the local node and other nodes in the network. The node on 
which network management functions are actually performed is called the 
executor node. Usually, the executor node will be the local node. You have 
the option, however, of entering at the local node one or more commands to 
be executed at a remote node. For those commands, the remote node serves 
as the executor node. 


2.1.1.1 Node Address and Name 

To configure an operational network at the local node, you must establish 
configuration database entries for the local node and for all adjacent nodes 
that are connected by circuits. It is recommended that you specify names 
and addresses for all nodes in the network. Once you have done so, you can 
reach any other node by its name. 

To satisfy routing requirements, each node in the network must have a unique 
address. The node address is a number in the form 

area-number.node-number 

The area-number is the number of the area in which the node resides and the 
node-number is the address of the node within that area. Each area number 
must be unique within the network and each node number unique within the 
area. If the area number is not specified in a node address, the area number 
of a remote node defaults to the area number of the executor node, and the 
area number of the executor defaults to the number 1. 

Node identification has two forms: a node address and a node name. A node 
address, a number in the format described above, is assigned to each node in 
the configuration database. A node name is an optional alphanumeric string. 
In the single-area network example in Chapter 1, the node assigned node 
address 1.11 is also identified by the node name BOSTON. In the multiple- 
area network example in Chapter 1, node BOSTON in area 2 has the node 
address 2.11. 

Because it is often easier to remember a name rather than an address, you 
may prefer to associate a name with an address. You can do so at any 
time. Note, however, that node names are known only to the local node 
network software while node addresses are known network-wide by the 
routing function. To avoid potential confusion, you should give each node a 
unique name that all nodes in the network will assign to that node and use to 
address it. 

Nodes on Ethernet lines can also be accessed under certain circumstances 
by their Ethernet addresses. All nodes connected to an Ethernet line are 
equally accessible, because the Ethernet is a multiaccess, broadcast device. 
Therefore, each node on an Ethernet is assigned a unique Ethernet physical 
address, which is set by the software at the node. You do not normally 
have to specify the Ethernet address of an individual node to configure your 
network or perform normal network operations. You do need to know a 
node's Ethernet physical address for service functions (such as downline load, 
circuit loopback test, and configurator operations). You can send a message 
to one, several, or all nodes on an Ethernet line simultaneously, depending 
on the Ethernet address used. To send a message to more than one node, 
use an Ethernet multicast address: either a multicast group address to reach 
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a selected group of nodes, or a broadcast address to reach all nodes on the 
Ethernet. 


2.1.1.2 Node Characteristics 

The configuration database for the local node must contain certain 
information about the local node and may contain node information for 
all nodes with which you want to communicate. For the local node, you 
must specify the node address and should specify the node name and buffer 
size (which determines the largest size message the node can forward). 

You should also indicate or use the default value for the highest address 
the local node will recognize, and for the node type (which determines the 
routing capabilities of the local node). Optionally, you can specify data link 
control information for the local node. For remote nodes, you should specify 
names and addresses. You can also specify default information to be used 
in performing downline load or upline dump operations involving remote 
nodes. For any or all nodes, you can specify access control information and 
node counter event logging information. 

To update your configuration database with current information about remote 
nodes in your network, you can copy the names and addresses of remote 
nodes from the database of another node to which you have access. You can 
specify the node database (volatile or permanent) to be copied, and the local 
node database (either or both volatile and permanent) to which information 
is to be copied. You also have the option of clearing or purging your local 
node database before copying the remote node data, thus avoiding possible 
conflicts between original and updated data. The executor node information 
is preserved during the clear or purge operation. Being able to copy a node 
database permits you to keep your network information current even if you 
are part of a large network that changes frequently. Alternatively, if you 
configure your node without a permanent node database, you could obtain 
current information on other nodes in the network when required by copying 
it from another node (for example, from a node on your Ethernet that serves 
as a master by keeping its node database up to date). 

The data link control information you can specify for the local node controls 
certain characteristics of physical line operation, including the size and 
number of transmit and receive buffers and the number of circuits the local 
node can use. These values should be set to levels that ensure reasonable 
system operation. It is important to set the buffers for all nodes in the 
network to the same size. Otherwise, packets will be dropped when routed 
through nodes with smaller buffer sizes. A procedure for changing the size 
of buffers on all nodes in the network without bringing down the whole 
network is given in Section 3.3.5.1. 

You can control the operational state of the local node and thereby control 
its active participation in the network. This control is usually a function 
of whether or not inbound logical link connections can be established or 
maintained with the local node. You can use this control to restrict the 
operation of the node or to shut it down altogether. 
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2.1.1.3 Identifying a VAXcluster as a Single Node 

A whole VAXcluster or some of the nodes in a VAXcluster can be represented 
by a special identifier called the alias node identifier, which appears to other 
nodes in the network to identify an actual node. This mechanism allows 
users on DECnet nodes outside the cluster to access cluster resources without 
knowing what the cluster nodes are or which are active. 

Any node in the cluster can elect to assume the alias node identifier while 
retaining its own unique node name and address. Use of the alias never 
precludes use of the individual node name and address. Thus a remote node 
can address the cluster as a single node, and address any cluster member 
individually. 

You can designate that your cluster node is assuming the alias node identifier 
by specifying in your configuration database either the alias node address or 
the alias node name (if you have previously associated that name with the 
alias address of the cluster). 

You then have the option of indicating whether you want to use the alias 
for incoming and/or selected outgoing connections. Specifically, you can 
indicate whether or not your node will accept incoming connection requests 
directed to the alias node address. By default, a node that assumes the alias 
will be available to receive incoming connections addressed to the alias, but 
a small node that uses the alias for outgoing traffic may elect not to handle 
the extra incoming traffic. You can also select which DECnet-VAX objects 
(software components that provide network services) are to use the alias 
by specifying in the object database that the alias address is to be used for 
outgoing connections originated by those objects. In addition, you can specify 
which objects will receive incoming connect requests directed to the alias 
node address. 

MAIL is an example of a network object that can effectively treat the cluster 
as a single node. Ordinarily, replies to mail messages are directed to the node 
that originated the message; the reply is not delivered if that node is not 
available. If the node is in a duster and uses the cluster alias, an outgoing 
mail message is identified by the alias node address rather than the individual 
address of the originating node. An incoming reply directed to the alias 
address is given to any active node in the cluster and is delivered to the 
originator's mail file. 

Objects that involve multiple incoming links (such as PHONE) should not 
use the alias node address because each incoming link may be routed to a 
different node that uses the same alias. Also, objects whose resources are 
not accessible clusterwide should not be allowed to receive incoming connect 
requests directed to the alias node address. Section 2.6 describes network 
objects and discusses the type of object for which the alias node identifier is 
suitable. 

The alias node identifier permits you to set a proxy to a remote node for the 
whole cluster rather than for each node in the cluster. The clusterwide proxy 
can be quite useful if the alias node address is used for outgoing connections 
originated by the object FAL, which accesses the file system. 

The alias node identifier should be used only for fully shareable resources in 
a VAXcluster. All processors in the cluster must be able to access and share 
all resources (such as files and devices). Nodes that assume the alias node 
identifier should have a common authorization file. 
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At least one of the cluster nodes that uses the alias node identifier must be 
a router. It can be a level 1 router, because all cluster nodes sharing the 
same alias node address must be in the same area. The cluster router informs 
other nodes in the network of the existence of the alias node address. Other 
routers in the network perceive the cluster router as the shortest path to the 
cluster node address and send the router packets addressed to the cluster 
node address. If the router receives a packet addressed to the alias node 
address, it forwards the packet to the appropriate cluster node: if the packet 
is for an existing logical link, the link identifier in the packet is sufficient to 
select the node; if the packet is initiating a new logical link, the router selects 
a participating node in round-robin fashion. 

The network manager or cluster manager should select a suitable alias node 
name and address for the cluster nodes. You can specify either the alias node 
name or address as an executor parameter in your node database. If you 
specify the alias node name, you must first have associated the name with the 
agreed-upon alias node address. You can then assign the same parameters to 
this node as to other nodes, except that routing initialization passwords are 
not required. No point-to-point initialization can occur because a node cannot 
set up a circuit to an alias node address. The alias node address and name 
will appear in the node databases of other nodes in the network. 

You can optionally set a maximum value on the number of logical links that 
your node can initiate using the alias node identifier (see Section 2.5). 


2.1.2 DTEs 


A VAX/VMS operating system with VAX PSI software installed can function 
as a DTE (or DTEs) capable of sending and receiving packets over PSDNs to 
which the system is connected. To configure a local DTE, you must establish 
in the configuration database an X.25 protocol module entry, which identifies 
a network to which your DTE is connected. This network represents a path 
to a PSDN. You must also establish X.25/X.29 server database entries that 
indicate the destinations of incoming X.25 and X.29 calls (see Section 2.7). 


2.1.2.1 X.25 Protocol Module 

The X.25 protocol module is a software component that controls the 
transmission of data packets over PSDNs. The configuration database for 
the X.25 protocol module identifies the networks to which your DTEs are 
connected, defines the DTEs, and specifies any user group to be associated 
with the DTEs. 

The first step in configuring the X.25 protocol module is to identify the 
particular networks to which your DTE or DTEs will belong. Note that the 
term "network" as used here refers to a network you define with NCP. In this 
context, network does not refer to a PSDN, but rather a route to a PSDN. 
You must associate the network name with a profile that determines the 
characteristics of subscription to the PSDN. When you specify a network 
profile, default values for a number of parameters that affect data-packet 
control are entered in the configuration database. Defaults set the size and 
control the flow of data packets over switched virtual circuits, and control 
call setup and clearing of these circuits; they also control the transmission of 
resets and restarts over permanent and switched virtual circuits. 

You identify your local DTE or DTEs by DTE address and network name. 
Each local DTE must have a unique address for each network to which it 
belongs. The DTE address format is determined by the PSDN whose profile 
is specified for the network. For each DTE, you can specify the operational 
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state and maximum number of circuits supported, and identify the associated 
line and the channels for outgoing calls. 

You should also identify any user group of which you are a member. A user 
group is an optional PSDN facility to which you can subscribe: a closed user 
group (CUG) permits two or more DTEs to communicate only with each 
other; a bilateral closed user group (BCUG) restricts communication to a 
pair of DTEs. Specify the unique name of your CUG or BCUG and associate 
with it the local DTE address and group number; for a BCUG, specify that the 
group type is bilateral. 


2.1.2.2 X.25 Connector and Host Nodes 

A VAX/VMS node that has VAX PSI software in multihost mode installed 
can serve as a connector node, a gateway that provides access to a PSDN 
for host nodes. To configure your node with VAX PSI software in multihost 
mode, establish in the database an X.25 protocol module entry as described in 
Section 2.1.2.1, then indicate in the X.25 server database the host destinations 
to which incoming calls are to be forwarded. 

A VAX/VMS host node must have VAX PSI Access software installed. To 
configure your node as a host node, you must establish in the database the 
X.25 access module (see Section 2.8) and indicate in the X.25 server database 
the destination on your node for incoming calls. 


2.2 Circuits 


Circuits are high-level communications data paths between nodes or DTEs; 
communication between nodes takes place over circuits. Circuits operate over 
physical lines, which are low-level communications paths (see Section 3.6). 


2.2.1 Classes of DECnet—VAX Circuits 

DECnet-VAX employs four classes of circuits: DDCMP, Cl, Ethernet, and 
X.25. 

DDCMP circuits provide the logical point-to-point or multipoint connection 
between two or more nodes. There are currently three types of DDCMP 
circuits: point-to-point, multipoint control, and multipoint tributary. A point- 
to-point circuit operates over a corresponding synchronous or asynchronous 
DDCMP point-to-point line. Asynchronous lines can be either static 
(permanent) or dynamic (switched). 

Multipoint control circuits operate over synchronous DDCMP control lines. 
You can specify multiple circuits from the control (master) end of a control 
line, but each circuit must have a unique physical tributary address. On the 
tributary (slave) end, you can specify only one multipoint tributary circuit per 
line. 

Cl circuits are available only on those nodes that are attached to a CI-780 
or CI-750 interconnect. Cl circuits are similar in many ways to DDCMP 
multipoint circuits, but use their own protocol. 

Ethernet circuits provide for multiaccess connection between a number of 
nodes on the same broadcast circuit. An Ethernet circuit differs from other 
DECnet circuits in that there is not a single node at the other end. An 
Ethernet circuit is a path to many nodes. Each node on a single Ethernet 
circuit is considered as being adjacent to every other node on the circuit 
and equally accessible. Every node must have a unique node identification: 
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an Ethernet physical address. (Ethernet node addressing is described in 
Section 3.3.4.) Ethernet circuits use the Ethernet protocol. 

X.25 circuits use the X.25 level 3 protocol (the packet level) and provide for 
communication over PSDNs. VAX PSI provides X.25 circuits for use by PSI 
user application programs (also referred to as "native X.25 user programs") 
or by DECnet data link mapping (DLM). DLM permits the use of X.25 as a 
DECnet data link through the mapping of data link information between the 
DECnet Routing layer and the X.25 protocol module. The two types of X.25 
circuits are X.25 native circuits and X.25 DLM circuits. 

Each X.25 circuit is a virtual circuit connecting a local DTE and a remote DTE. 
An X.25 virtual circuit can be either of the following: 

• A permanent virtual circuit (PVC), providing a permanent path between 
the local DTE and the remote DTE 

• A switched virtual circuit (SVC), providing a temporary path between the 
local DTE and the remote DTE 


The PVCs can be used by DECnet and native X.25 user programs for X.25 
communications with a PSDN. SVCs can be used by both DECnet and 
native X.25 user programs, but only SVCs used by DECnet through data 
link mapping (DLM) need to be set up by means of NCP commands. VAX 
PSI sets up X.25 native SVCs with parameters taken from the X.25 protocol 
module component when calls on these circuits are requested. You do not 
need to use NCP to set up X.25 native SVCs. 

Just as you must specify the local node, you must also specify parameters for 
all DECnet circuits connected to the local node and all X.25 virtual circuits 
connected to local DTEs. 

You must identify each circuit by name and specify information that directly 
affects the circuit's operation. You can also specify the operational state of 
circuits connected to your local node or DTE. Thus you can control circuit 
traffic and perform service functions. The state of a circuit may ultimately 
affect the system's ability to reach an adjacent node or DTE. The circuit state 
can have a similar effect on routing. 

This section describes the circuit component. For a discussion of using NCP 
commands to specify circuits, see Chapter 3. 


2.2.2 DDCMP Circuit Devices 

DDCMP circuit devices can be synchronous or asynchronous. DECnet-VAX 
supports the following synchronous DDCMP circuit devices: 

• DMC11 

• DMR11 

• DMP11 

• DMV11 

• DMF32 synchronous line unit 
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The DMC11 and the DMR11 are point-to-point circuit devices and are 
considered identical. The DMP11 can be a point-to-point, multipoint control, 
or multipoint tributary circuit device. The DMV11 is similar to the DMP11; 
DECnet refers to both devices as the DMP11. The DMF32 synchronous line 
unit is either a point-to-point or multipoint tributary circuit device. 

DECnet-VAX supports the following asynchronous DDCMP circuit devices: 

• DHU11 

• DHV11 

• DZ11 

• DZ32 

• DZV11 

• DMZ32 

• DMF32 asynchronous line unit 

The DZ11, DZ32, and DZV11 are represented by the mnemonic TT. 

The DHU11, DHV11, DMZ32, and DMF32 asynchronous line units are 
represented by the mnemonic TX. The asynchronous circuit devices are point- 
to-point circuit devices used for static or dynamic asynchronous connections. 

Note that asynchronous DDCMP circuits need not be predefined for dynamic 
connections. They are established automatically during dynamic switching of 
terminal lines (see Section 2.3.2.3). 

Other DECnet implementations may support other DDCMP circuit devices. 

If a node in your network uses a circuit device other than one of these, refer 
to the appropriate DECnet documentation. This section provides a general 
discussion of point-to-point and multipoint circuits. The VAX/VMS Network 
Control Program Reference Manual lists DECnet circuit and line devices by 
name and operational category. 

Every DDCMP circuit provides a logical point-to-point connection between 
two nodes. The circuit operates over the corresponding DDCMP line (for 
example, the DMC11 circuit operates over the DMC11 line). The DMP11, 
operating as a multipoint control circuit, also provides a logical, multipoint 
connection (over one physical line) between a control station and several 
tributaries (as illustrated in Figure 2-1). The DMP11 and DMF32 can also 
operate as multipoint tributary circuit devices that provide a logical connection 
between a tributary and a control station. 

The following terms are used in describing the operation of multipoint 
circuits: 

• Control Station. The control station is the node at the controlling end of 
a multipoint circuit. It controls the tributaries for that circuit. 

• Polling. Polling is the activity that the control station performs on 
tributaries of a multipoint circuit. The control station regularly sends 
request messages to (that is, polls) each eligible tributary in the polling 
list. The request message asks the tributary if it has anything to send 
(essentially giving it permission to use the bus). 

• Tributary. A tributary is a physical termination point on a multipoint 
circuit that is not a control station. 
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Figure 2-1 Multipoint Circuits and Associated Lines 
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• Tributary Address. A tributary address is a numeric address that 
identifies a tributary node on a multipoint circuit. 

It is possible to connect both a multipoint control circuit and a multipoint 
tributary circuit to the same node. The node could then serve as the control 
station for one multipoint circuit and as a tributary for another multipoint 
circuit. 

The system manager must supply tributary addresses for a control station to 
use when polling each tributary in a polling list. 
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2.2.3 Cl Circuit Device 

DECnet supports the CI-780 interconnect (on VAX-11/780, VAX-11/782, or 
VAX-11/785 processors only) and the CI-750 interconnect (on VAX-11/750 
processors only). All nodes connected to the same Cl bus can communicate 
directly with each other. Only one Cl controller per node is required. DECnet 
treats the Cl controller as a multipoint data link and requires a single entry 
in the line database and multiple entries in the circuit database. The line 
database entry describes the Cl controller (see Section 3.6). Each circuit 
database entry describes a virtual connection to a single remote node on 
the Cl. Cl multipoint circuits and DDCMP multipoint circuits differ in the 
following ways: 

• Each station on the Cl can talk directly to every other station. These 
stations are called tributaries and all stations are alike. There are no 
"control" and "tributary" stations as with DDCMP multipoint circuits. 

• There are no polling parameters on the Cl. 

• Cl circuits use their own communication protocol. 

If you plan to use a Cl circuit, you must first connect the device CNAO to 
the driver CNDRIVER. To connect CNAO to the CNDRIVER and load the 
CNDRIVER, add the following to the LOADNET.COM command procedure 
in SYS$MANAGER: 

$ RUN SYS$SYSTEM:SYSGEN 
CONNECT CNAO/NOADAPTER 


2.2.4 Ethernet Circuit Device 

DECnet supports the DEUNA, DELUA, and DEQNA circuit devices, which 
provide for multiaccess connections between many nodes on the same 
Ethernet circuit. The VAX/VMS system uses the DEUNA or DELUA circuit 
device (each of these devices is called the UNA). The DELUA is a newer 
version of the DEUNA that provides higher throughput. The MicroVMS 
system uses the DEQNA (referred to as the QNA), which is similar in 
function to the DEUNA. The UNA and QNA use the Ethernet protocol. 
Ethernet messages are sent over the Ethernet as datagrams, which means 
messages may be lost because of errors. DECnet provides for automatic 
retransmission of lost messages. The Ethernet device allows multiple users of 
the device at the same time; therefore, other users may be using the UNA or 
QNA on another type of protocol while DECnet is running. 


2.2.5 Ethernet Configurator Module 

All nodes on an Ethernet circuit are logically adjacent, because the Ethernet 
is a multiaccess device. To obtain a list of all systems on an Ethernet circuit, 
you can use the Ethernet configurator module. The configurator module 
listens to system identification messages transmitted periodically by every 
DIGITAL-supported node on the Ethernet circuit, and builds the configuration 
list from the received messages. 

Approximately once every 10 minutes, each node on an Ethernet circuit that 
conforms to the DNA specifications transmits a system identification message 
(a hello message) to a multicast address that the configurator monitors. For 
a random distribution of nodes with possible loss of system identification 
datagrams, the configurator would require 40 minutes to collect all node 
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addresses. In practice, the configurator normally requires about 12 minutes to 
complete a list. 

The Ethernet configurator module requires a default nonprivileged DECnet 
account. Use NCP commands to access and control the configurator module. 
The configurator runs as a separate process and, once it is started, becomes 
available to all users on the system. The configurator module will continue 
to execute and will maintain and update its database of information on active 
nodes. 

When you request information on the current configuration of nodes on 
Ethernet circuits, the following is displayed for each system: its Ethernet 
physical and hardware addresses, the device connecting it to the circuit, 
maintenance functions it can perform, and the time of the last system 
identification message from the system. 


2.2.6 X.25 Circuit Devices 

X.25 circuits differ from DDCMP circuits in that there is no direct 
correspondence between circuit and line. All X.25 circuits pass through 
the X.25 protocol handler module (see Section 2.1.2.1), which multiplexes 
circuits to lines that it "owns." There is no direct relationship between the 
name of an X.25 circuit and an X.25 line. One line is specified for each DTE. 

All X.25 circuits are virtual circuits that connect a local DTE with a remote 
DTE. The association between DTEs can be permanent or temporary. X.25 
PVCs are analogous to leased lines between the local DTE and the remote 
DTE. They are similar to DDCMP circuits in that both have predefined end 
points. 

X.25 SVCs are analogous to dialup lines. SVCs are set up only when there 
is data to transmit and are cleared when the transfer is complete. They are 
temporary paths between local and remote DTEs. 


2.2.7 X.25 DLM Circuits 

Data link mapping (DLM) circuits extend normal DECnet capabilities to 
include communication over a PSDN with other DECnet nodes connected to 
the PSDN. Data link mapping permits an X.25 virtual circuit to be used as a 
DECnet data link. A DLM circuit is owned by the executor node; the Routing 
layer has exclusive rights to use the circuit. A DLM circuit can be either a 
PVC or an SVC. A DLM SVC can be used for either incoming or outgoing 
calls. 

To establish a DLM SVC with a remote DTE, DECnet-VAX uses the DTE 
address of the remote node. Subaddresses can be used to limit the DLM 
calls accepted at the local DTE. DECnet-VAX will try to recall a number if 
previous attempts to establish a DLM SVC have not succeeded. The number 
and frequency of recall attempts can be regulated. 


2.3 Lines 


Lines provide physical communications and are the lowest level 
communications path. Circuits are high-level communications paths that 
operate over lines. 
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2.3.1 Classes of DECnet—VAX Lines 

DECnet-VAX supports four classes of lines: DDCMP, Cl, Ethernet, and X.25. 
A DDCMP line provides the physical point-to-point or multipoint connection 
between two or more nodes. A Cl line provides a high-speed connection 
between two or more nodes. An Ethernet line is a multiaccess connection 
between two or more nodes. An X.25 line is the physical link between your 
DTE and a PSDN. 

For DDCMP, Cl, and Ethernet configurations, each circuit is directly related to 
a corresponding line. For X.25 configurations, however, the circuits and lines 
do not correspond directly. X.25 circuits are multiplexed to lines owned by 
the X.25 protocol handler module (see Section 2.1.2.1). 

Just as you must establish node and circuit parameters, you must also 
establish parameters for all physical lines connected to the local node or 
DTE. You must identify each line by name and specify information that 
directly affects the line's operation. You can control the operational state of 
the line, and thus control line traffic and perform service functions. The state 
of a line may ultimately affect the reachability of an adjacent node or DTE, 
affecting the routing. 

This section describes the line component. For a discussion of using NCP 
commands to specify line parameters, see Chapter 3. 


2.3.2 DDCMP Lines 


DDCMP lines can be synchronous point-to-point or multipoint lines 
or asynchronous point-to-point lines. Asynchronous lines can be static 
(permanent) or dynamic (temporarily switched). 


2.3.2.1 DDCMP Line Devices 

DDCMP line devices can be synchronous or asynchronous. DECnet-VAX 
supports the following synchronous DDCMP line devices: 

• DMC11 

• DMR11 

• DMP11 

• DMV11 

• DMF32 synchronous line unit 

The DMC11 and the DMR11 are point-to-point line devices and are 
considered identical. The DMP11 can be either a point-to-point, multipoint 
control, or multipoint tributary line device. The DMV11 is similar to 
the DMP11; DECnet refers to either device as the DMP11. The DMF32 
synchronous line unit is a point-to-point or multipoint tributary line device. 

DECnet-VAX supports the following asynchronous DDCMP line devices: 

• DHU11 

• DHV11 

• DZ11 

• DZ32 

• DZV11 


2-12 





DECnet—VAX Components and Concepts 


• DMZ32 

• DMF32 asynchronous line unit 

The DZ11, DZ32, and DZV11 line devices are represented by the mnemonic 
TT. The DHU11, DHV11, DMZ32, and DMF32 asynchronous line units are 
represented by the mnemonic TX. The asynchronous line devices are point- 
to-point line devices used for static or dynamic asynchronous connections. 

Note that asynchronous DDCMP lines need not be predefined for 
dynamic connections. They are established automatically when a dynamic 
asynchronous DDCMP connection is made (see Section 2.3.2.3). 

Every DDCMP line provides a point-to-point connection between two nodes. 
Circuits, the actual communications path, operate over the line. The DMP11 
and DMF32 also provide a multipoint connection between two or more 
nodes. In Figure 2-2 a multipoint line controlled by the DMP11 provides the 
physical connection between a control node and several tributary nodes. 

Figure 2-2 Multipoint Lines 
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It is also possible to connect two multipoint lines to the same node. The 
node could then serve as the control station for one multipoint line and as a 
tributary for another multipoint line. 


2-13 











DECnet—VAX Components and Concepts 


Because a heterogeneous network such as the network example in this 
manual may have DDCMP line devices other than one of the above, you 
should be familiar with the entire range of devices and their impact on 
network management. Refer to the appropriate DECnet documentation if a 
node in your network uses a line device other than these. The VAX/VMS 
Network Control Program Reference Manual lists DECnet line devices by name 
and operational category. 


2.3.2.2 Static Asynchronous Lines 

A static asynchronous DDCMP connection is a permanent connection 
established between two nodes (such as a Micro VMS end node and a 
VAX/VMS router). The two nodes are connected by a physical line attached 
to a terminal port at each end (for example, port TTAO on the end node and 
port TXB7 on the router). A static asynchronous connection can also be made 
over a dialup line. 

Before the DECnet connection is made, the terminal lines must be converted 
to static asynchronous DDCMP lines. Each terminal port must have an 
asynchronous DDCMP line device installed, and the system manager at 
each node must load the asynchronous DDCMP driver, NODRIVER. The 
system manager at each node should insert the following command in the 
LOADNET.COM command procedure: 

$ SET TERMINAL/PROTOCOL=DDCMP device-name: 

The device-name is the name of the appropriate terminal port. For example, 
the Micro VMS manager should specify the command 

$ SET TERMINAL/PROTOCOL=DDCMP TTAO: 

and the VAX/VMS manager should specify 

$ SET TERMINAL/PROTOCOL=DDCMP TXB7: 

Each system manager should then specify the appropriate line and circuit 
commands in the configuration database to turn the line and circuit on for 
DECnet use. (The commands required to install static asynchronous lines and 
the NCP commands to configure a network using static asynchronous lines 
are given in Chapter 5.) 


2.3.2.3 Dynamic Asynchronous Lines 

A dynamic asynchronous line differs from a static asynchronous line or other 
DECnet-VAX line in that it is normally switched on for network use only for 
the duration of a dialup connection between two nodes. When the telephone 
is hung up, the line reverts to being a terminal line. 

Figure 2-3 illustrates a typical configuration in which dynamic asynchronous 
switching occurs over a dialup line. The local node in the figure is a 
standalone Micro VAX system; the remote node is a VAX-11/780. After 
the user at the local node dials in to the remote node, he can cause the 
lines connected to terminal ports TTA1 and TXB1 to be switched to dynamic 
asynchronous DDCMP lines for use in DECnet communications. 

Dynamic switching of terminal lines to asynchronous DDCMP lines can 
occur provided both nodes have DECnet-VAX licenses installed. The system 
manager at each node must have loaded the asynchronous driver NODRIVER 
and installed the privileged shareable image DYNSWITCH. The system 
manager at the remote node must have enabled virtual terminals on the 
system. In particular, the system manager must have enabled the virtual 
terminal for the line over which you are going to log in and must have-set 
the DISCONNECT attribute for that line. 
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Figure 2-3 Dynamic Switching of Asynchronous DDCMP Lines 
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The procedure for dynamic switching of lines is as follows: 

1 You should log in to the Micro VMS system through the terminal port 
TTAO, causing a process (PROCESS—L) to be created on your system. 

2 You must issue the following DCL command: 

$ SET HOST/DTE[/DIAL=NUMBER:number] TTA1: 

This command causes the local system to function as a terminal emulator, 
and causes the modem to dial the number of the remote system. The 
terminal emulator permits the local processor to function as though it 
were a terminal line: characters can be read from one port and written 
to another port. In this figure, the terminal emulator on the Micro VAX 
reads characters from port TTAO and writes characters to port TTA1. Note 
that the /DIAL qualifier in the SET HOST/DTE command is optional 
and works only if you have written a program to dial your modem. The 
default program supplied with VAX/VMS dials a DF03 modem. 

3 Once the dialup connection is made and you receive the remote system 
welcome message, you should perform the regular procedure for logging 
in to your account on the remote node. In this example, you would supply 
your user name and password to the VAX/VMS system. 

4 When you log in over a modem line, a process (PROCESS—R) is created 
at the remote node and connected to a virtual terminal as well as the 
physical terminal. The virtual terminal permits PROCESS—R to continue 
running even if the physical terminal is disconnected (for example, if you 
lose the carrier signal on your telephone line). 

5 You can then initiate dynamic switching by specifying the following DCL 
command from your account on the remote node: 

$ SET TERMINAL/PROTOCOL«DDCMP/SWITCH=DECNET 

(To switch your line manually, see step 10.) 

6 When the SET image at the remote node recognizes the 
/SWITCH=DECNET qualifier, it calls the shareable image DYNSWITCH. 
DYNSWITCH verifies that the device is a virtual terminal and then sends 
an escape sequence to the terminal emulator running on the Micro VAX. 
The escape sequence notifies the terminal emulator that the line connected 
to the remote terminal port is becoming an asynchronous DDCMP line. 

7 When the terminal emulator at the local node receives the escape 
sequence, it calls the image DYNSWITCH, which causes the line 
connected to terminal port TTA1 to be switched to an asynchronous 
DDCMP line. It assigns a channel to the network and supplies the 
appropriate line and circuit entries to the NCP volatile database at the 
local node. (Note that the modem line is not dropped; redialing is not 
required.) 

8 The asynchronous DDCMP protocol on the local node then sends 
a DDCMP start message to DYNSWITCH on the remote node. 
DYNSWITCH at the remote node disconnects the physical terminal from 
the virtual terminal, and causes the line connected to the physical terminal 
port (in the figure, the port TXB1) to be converted to an asynchronous 
DDCMP line. DYNSWITCH assigns a channel to the network and 
supplies the appropriate line and circuit parameters to the volatile database 
to start up the line and circuit. 
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9 After DECnet is started on the local node, the terminal emulator is exited 
and control is returned to the local node with the following message: 

'/, REM-S-END - control returns to local-node-name:: 

A prompt appears on the local terminal and you can then use DECnet to 
perform operations over the network. 

I 0 If the terminal emulator does not recognize escape sequences, you must 

specify the /MANUAL qualifier in the SET TERMINAL command 
indicated in step 5. The /MANUAL qualifier prevents DYNSWITCH 
at the remote node from sending the escape sequence. Instead, 
DYNSWITCH sends the following message to the local node 

V. SET-I-SWINPRG The line you are currently logged in 
over is becoming a DECnet line 

After receiving this message, if you decide not to switch the line, you can 
type CTRL/C or CTRL/Y to abort the switch. If you want to continue the 
switch, you should exit the terminal emulator and switch your terminal 
line to an asynchronous DDCMP line manually by specifying 

$ SET TERMINAL/PROTOCOL=DDCMP TTA1: 

and entering NCP commands to turn your line and circuit on. 
DYNSWITCH waits 60 seconds for the DDCMP start message and then 
times out the switch. 

Note that the SET TERMINAL command is a VAX/VMS DCL command. 
If you are on a non-VAX/VMS node, you should specify the equivalent 
function for your system. 

II When you hang up the line, it is switched back to a terminal line. 
(DECnet-VAX automatically clears the line and circuit entries from the 
volatile database). Alternatively, you can switch the asynchronous line 
back to a terminal line by issuing an NCP command to turn the line or 
circuit off. 

If you specified the /NOHANGUP qualifier in the SET TERMINAL 
command in step 5, the modem signal is not dropped if you specify an 
NCP command to turn off the DECnet line. You will not have to redial 
the connection to the remote node when you want to convert your line 
to DECnet use. The modem signal is dropped when you hang up the 
telephone. 

Examples of the commands required to install dynamic asynchronous lines 
and the NCP commands required to configure a network using dynamic 
asynchronous lines are given in Chapter 5. 

NCP command parameters required for asynchronous connections are 
described in Chapter 3. Security for dynamic asynchronous connections 
is summarized in Section 2.10. 


2.3.3 Cl Line Device 


The CI-780 and CI-750 lines are high-speed devices, each of which provides 
a connection between two or more nodes. If you plan to run DECnet over 
a Cl, you must first connect the device CNAO to the driver CNDRIVER. To 
connect CNAO to the CNDRIVER and load the CNDRIVER, add the following 
to the LOADNET.COM command procedure in SYS$MANAGER: 


$ RUN SYS$SYSTEM:SYSGEN 
CONNECT CNAO/NOADAPTER 
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2.3.4 Ethernet Line Device 

A VAX/VMS Ethernet node is connected to the Ethernet line by the 
DEUNA communications controller, a transceiver, and a transceiver cable. 
(Alternatively, a DELUA controller can be used instead of the DEUNA; 
both devices are referred to as UNA devices.) A MicroVMS Ethernet node 
uses the DEQNA controller to perform the same functions as the DEUNA 
controller. (The DEQNA device is called the QNA.) The Ethernet line device 
that provides the physical connection between two or more nodes on the 
same Ethernet cable is the UNA, for a VAX/VMS node, or the QNA, for a 
MicroVMS node. The UNA and QNA use the Ethernet line protocol. The 
Ethernet circuit operates over the Ethernet line. 

A particular Ethernet node is identified by the Ethernet hardware address 
of its line device; this hardware address is stored in read-only memory in 
the DEUNA, DELUA, or DEQNA. When DECnet starts an Ethernet line, it 
causes the DEUNA, DELUA, or DEQNA connected to the line to construct 
an Ethernet physical address for the node (see Section 3.3.4). Conditions that 
cause the DEUNA, DELUA, or DEQNA to reset the physical address to the 
original hardware address are shutting off machine power or changing the 
state of the Ethernet line to OFF. 


2.3.5 X.25 Line Devices 

VAX PSI supports the following line devices: 

• DMF32 synchronous line unit 

• DUP11-DA 

• DPV11 

• KMS11-BD 

• KMS11-PX/PY 

• KMV11 

The DPV11 is equivalent to a DUP11. The DMF32 synchronous line unit 
is a point-to-point or multipoint tributary circuit device. The DUP11-DA 
is a low-speed synchronous interface. The combination of the KMS11-BD 
controller hardware and the X.25 level 2 microcode provides a medium-speed 
synchronous interface called the KMX. The KMS11-BD supports eight lines, 
but all lines that are used must be connected to the same PSDN. Similarly, 
the combination of the KMS11-PX controller hardware and the X.25 level 2 
microcode provides a medium-speed synchronous interface called the KMY, 
supporting one line. The KMV11 is equivalent to a KMY. 

Refer to the VAX PSI documentation set for the most recent list of supported 
X.25 line devices. 
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2.4 Routing 

Routing is the network function that determines the path or route along 
which data (called "packets" in this context) travels to its destination. The 
Routing layer of DECnet handles routing functions. Because the need for 
routing pervades network operation, as much as possible is done in software 
to relieve the user from worrying about the configuration of the network. 

As system manager, however, you need to be concerned with the 
configuration of the network in terms of routing. You must configure each 
network node as either a routing or a nonrouting node, and you have the 
option of dividing the whole network into different areas. In addition, certain 
parameters in the configuration database permit a degree of indirect control 
over network routing, but, for most networks, the default values of these 
parameters are reasonable. 

For very large networks, it may be helpful to have a network manager 
oversee the operation of the network as a whole. The network manager could 
ensure that all node addresses are unique and that routing control parameters 
provide for efficient data flow through the network. 

This section explains the different types of routing and nonrouting nodes 
and configurations, describes the levels of routing, and summarizes special 
routing techniques used with Ethernet. It also introduces basic terms and 
concepts involved in routing control. The NCP command parameters that 
affect routing are discussed in Chapter 3. 


2.4.1 Routing and Nonrouting Nodes 

Routing nodes (routers) are nodes that can send and receive packets and 
route packets from one node to another. Routers have two or more circuits. 
Routers regularly receive and maintain information about other nodes. They 
perform the routing operation by associating a circuit with the destination 
node for the packet and transmitting that packet over that circuit. Routers can 
use DDCMP, Cl, Ethernet, or X.25 circuits as their data links. 

In a multiple-area network, all routers in a particular area can route packets 
within the area; certain of these routers can also route packets to and from 
other areas. The two kinds of routers used in area routing configurations are 
level 1 routers and level 2 routers. 

The level 1 router performs intra-area routing within a single area of the 
network. Note that if all nodes are configured in the same area, the whole 
network is considered as a single area, and all routers are level 1 routers. The 
level 2 router performs intra-area routing within its own area and interarea 
routing between its area and one or more other areas of the network. 

Nonrouting nodes (end nodes) contain a subset of network software that 
permits them to send packets or receive packets addressed to them, but not to 
route packets to other nodes. End nodes have a single circuit connecting them 
to the rest of the network. They do not send or receive information about 
network configurations. If two end nodes are connected by a nonbroadcast 
circuit, these nodes constitute the entire network. 

On an Ethernet, if there are two or more routers, one router is elected the 
designated router to provide message routing services for end nodes on the 
Ethernet. If no routers are available, Ethernet end nodes can communicate 
with each other directly, by sending a packet out over the Ethernet and then 
waiting, until the timeout, for a reply. However, routers are the only Ethernet 
nodes that can route messages to network nodes not on the Ethernet. 
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2.4.1.1 Types of DECnet Nodes 

DECnet supports a variety of types of nodes developed during different 
phases of DNA implementation. Phase II, III, and IV nodes can all exist on a 
network. The following types of nodes can be configured as being adjacent to 
each other: 

• Phase II/Phase II 

• Phase II/Phase III 

• Phase Ill/Phase III 

• Phase Ill/Phase IV 

• Phase IV/Phase IV 

Phase II nodes can communicate with each other as long as there is a physical 
data link between them. They support only point-to-point connections. There 
is no Phase II support for Ethernet. 

Phase III DECnet introduced adaptive routing, which allows a reasonably 
large number of nodes to communicate conveniently. A network composed 
of Phase III nodes is limited to a practical size of approximately 100 
nodes, because of the overhead of routing update messages that have to 
be exchanged among routers. (The design limit for the address of a DECnet- 
VAX Phase III node is 255; this limit may vary for other DECnet Phase III 
systems.) Phase III introduced routers and end nodes. Phase III depends 
on data links that guarantee delivery of messages in order to accomplish 
initialization among routers. Therefore, there is no Phase III support for 
Ethernet. 

Phase IV DECnet permits the configuration of very large networks and 
expands the types of data links available for use. Phase IV supports area 
routing, which allows configuration of a network of up to 63 areas, each 
containing up to 1023 nodes. Phase IV software supports Ethernet circuits, as 
well as DDCMP, Cl and X.25 circuits. 

Phase IV nodes can speak to Phase III nodes. Certain restrictions apply, 
however, in a mixed Phase Ill/Phase IV network: 

• A Phase III node should not be included in a path between Phase IV 
nodes. 

• A Phase III node in a Phase IV multiple-area network should not be linked 
with nodes outside its own area. 

• Routing initialization passwords (described in Section 2.10.1) are required 
when a Phase III node is initialized in a Phase IV network. 

Restrictions on the use of Phase III nodes in Phase IV networks are discussed 
in detail in Section A.5. 
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2.4.1.2 DECnet-VAX Phase IV Nodes 

DECnet-VAX Phase IV nodes are either of the following two types: 

• Phase IV routers. These nodes deliver packets to and receive packets from 
other nodes, and route packets from other source nodes through to other 
destination nodes. They use Ethernet, DDCMP, X.25, and Cl circuits. In 
an area network configuration. Phase IV routers exist at two routing levels: 

— The level 1 router, which performs routing within a single area. The 
node type is ROUTING IV. 

— The level 2 router, which performs routing within its own area and to 
and from other areas. The node type is AREA. 

• Phase IV nonrouting nodes (end nodes). These nodes deliver packets 
to other nodes and receive packets from other nodes, but do not route 
packets through. They can be attached to an Ethernet, DDCMP, X.25, or 
Cl circuit. The node type is NONROUTING IV. 

DECnet-VAX Phase IV nodes can also communicate with the other types of 
nodes supported by DECnet. Area numbers are dropped when a Phase IV 
node communicates with a node that is not a Phase IV node. A Phase IV 
node will add its executor area number to the node address of a message that 
it receives from a Phase III node. Nodes with which Phase IV DECnet-VAX 
nodes can communicate include: 

• Phase III routers. These nodes deliver packets to and receive packets from 
other nodes, and route packets from other source nodes through to other 
destination nodes whose addresses are less than 256. They use DDCMP, 
X.25, and Cl circuits, but do not support Ethernet circuits. 

• Phase III nonrouting nodes (end nodes). These nodes send packets to 
other nodes and receive packets from other nodes, but do not route 
packets through. These nodes cannot support the Ethernet. DECnet-VAX 
never provided this type of node, but can communicate with Phase III end 
nodes (for example, RSX Phase III end nodes). 

• Phase II nodes. These nodes can send packets to adjacent Phase III routers 
or to other adjacent Phase II nodes. However, Phase II nodes can send 
packets only in point-to-point configurations. In addition, a Phase III node 
cannot communicate with a Phase II node through another Phase III node. 


2.4.1.3 Routing Features of DECnet-VAX License Options 

The DECnet-VAX license you purchase determines the types of nodes you 
can configure. DECnet-VAX offers the option of installing a key for either of 
two kinds of DECnet-VAX license: 

• The full function license permits the node on which the appropriate key 
has been installed to be configured as either a router or an end node. 

• The end node license permits the node on which the appropriate key has 
been installed to be configured only as an end node. 

Both licenses permit the use of any kind of data link (DDCMP, Cl, Ethernet, 
X.25). Installation of the DECnet-VAX license key is described in Section 6.1. 

A configuration consisting only of end nodes offers certain advantages: 

• Less use of the central processor is required for routing. 
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• Data link efficiency is increased: there is no routing overhead and no 
route-through traffic occurs over the circuit. 

End nodes also involve the following limitations: 

• The user on an end node cannot directly see the status of other nodes in 
the network, because end nodes rely on routing nodes to maintain that 
information. However, a Phase IV end node can communicate with all 
nodes in the network, including nodes outside its own area. 

• At most, only one circuit is allowed to be active. If that one link to the 
network fails, no alternative connection is available until the system 
manager turns on a standby data link, if one exists. 


2.4.2 Area Routing 

Phase IV DECnet permits implementation of very large networks through 
the use of area routing techniques, while still supporting configuration of 
smaller networks that are not divided into areas. The network manager has 
the option of partitioning a large network into areas. Each area is a group of 
nodes. Nodes are grouped together in areas for hierarchical routing purposes. 
Hierarchical routing involves the addition of a second level of routing to the 
network. Routing within an area is referred to as level 1 routing; routing 
between areas is called level 2 routing. 

Area routing offers the following advantages: 

• It permits configuration of very large networks of more than 1023 nodes. 

• It requires less routing traffic, restricting routing overhead between areas 
to the level 2 routers. Level 1 routers exchange routing information only 
about nodes in their own area. 

• It allows different organizations to manage their nodes separately within a 
large network. 

• It makes the merging of existing networks easier. 

When a level 1 router receives a packet destined for a node in another area, 
it uses level 1 routing to send the packet to the nearest node within its own 
area that can perform level 2 routing. That router forwards the packet by 
level 2 routing to a level 2 router in the destination area, which in turn sends 
the packet by level 1 routing to the destination node in its area. 

Note that if two or more level 2 routers exist in the same area, each level 1 
router in that area sends packets destined for other areas to the nearest level 
2 router, regardless of which level 2 router is closest to the destination area. 
The level 1 router has no access to level 2 routing information. 

Each area in the network is assigned an area number. Every node in the area 
is uniquely identified by the addition of its area number as a prefix (followed 
by a period) to its node number. For example, node 15 in area 7 is addressed 
as node 7.15. The node/lumber must be unique within the area, but may be 
used again within another area. Thus node identification within an area is 
independent of node identification within other areas. 

Phase IV DECnet permits configuration of a maximum of 63 areas (areas 1 
through 63), each containing up to 1023 nodes. A Phase IV node address 
is a 16-bit number: the most significant six bits define the area number, 
and the least significant 10 bits specify the node number within the area. 

The Phase IV node address can be converted to its decimal equivalent 
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for use in commands, such as COPY and MAIL commands, that do not 
recognize the area prefix (the conversion procedure is given in Section 3.7.2). 
It can be converted to its hexadecimal equivalent for use in determining the 
Ethernet physical address of the node (the conversion procedure is given in 
Section 3.3.4.2). 

You assign the node address to your own node when you configure it. If you 
do not specify the area number when addressing a remote node, that node is 
assumed to be in the same area as your local node. 

In a network not divided into multiple areas, each router performs level 1 
routing throughout the network. 

The characteristics of level 1 and level 2 routing nodes are described in the 
following section. Appendix A presents rules for configuring hierarchical 
networks using area-routing techniques. This appendix also describes the 
configuration of mixed area networks, involving Phase III and Phase IV 
nodes, and recommends procedures for converting a nonarea network to an 
area network. 


2.4.3 Level 1 and Level 2 Routers 

An area can contain many level 1 routers and end nodes, and must contain 
at least one level 2 router to provide the connection to other areas. A level 

1 router acts as a standard routing node. It keeps information on the state 
of nodes within its own area. Level 1 routing nodes and end nodes obtain 
access to nodes in other areas through a level 2 router residing in their own 
area. 

A level 2 router keeps information on the state of nodes in its own area 
and also information on the cost and hops involved in reaching other areas. 
(The logical distance between adjacent level 2 nodes is one hop.) The level 

2 router always routes packets over the least cost path to a destination area. 
Level 2 routers have the following characteristics: 

• Level 2 routers connect areas together. 

• Level 2 routers also act as level 1 routers within their own area. 

• Each level 2 router in a network must be physically connected to at least 
one other level 2 router. 

• A level 2 router serves as a level 1 router when it is not physically 
connected to another level 2 router. 

• All level 2 routers must be connected in such a way that they create a 
network of their own. 

• Level 2 routers exchange level 2 routing messages among themselves. 

• In any given area, there can be more than one level 2 router. 

• Each level 2 router indicates it is the nearest level 2 router to each level 1 
node in its own area, but each level 1 node decides what its level 2 router 
is on the basis of cost. 
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2.4.4 Ethernet Routers and End Nodes 

Two special concepts are involved in routing over an Ethernet circuit: the 
designated router and end node caching. 


2.4.4.1 Ethernet Designated Routers 

If there are two or more routers on the same Ethernet, one of them is elected 
as the designated router. By convention the router with the highest numerical 
priority (the router priority parameter is set as a CIRCUIT characteristic in 
its database) is elected router for the circuit. In case of a tie, the node with 
the highest address is elected as the designated router. The function of the 
designated router is to route messages over the Ethernet on behalf of end 
nodes. A designated router is elected even if there are no end nodes currently 
on the Ethernet. 

Ethernet end nodes can also exchange messages directly without using a 
router. Routers are needed, however, when messages are to be routed to 
nodes off the Ethernet. 

Ethernet end nodes are informed of the identity of the designated router on 
that Ethernet. End nodes transmit multicast hello messages, so that routers 
know of their presence on the Ethernet. End nodes keep no information 
about the network configuration, except that they are permitted to keep 
a cache of nodes within their area that they may address directly on the 
Ethernet, rather than going through a router (see the description of Ethernet 
end node caching below). Thus an end node may send a packet directly to 
another Ethernet end node, if the address has been cached, or it may send a 
packet to the designated router for forwarding. 

Note that end nodes can exist on an Ethernet without a router. When an end 
node on the Ethernet wishes to communicate with another end node, and 
notes that no designated router exists, it will always send the packet directly 
to the addressed node. If the addressed node is active, the sender will receive 
a reply; if the addressed node is not available, a timeout will occur. 


2.4.4.2 Ethernet End Node Caching 

End nodes normally send packets by means of a router. To minimize the 
space and time overhead involved in the routing function on Ethernet circuits, 
a caching mechanism is available that takes advantage of the fact that nodes 
on an Ethernet are logically one hop away from each other (one hop is the 
distance between two adjacent nodes). 

When a designated router is present and an end node is ready to send a 
packet to a node for the first time, the end node sends the packet to the 
designated router. When there is no designated router on the circuit, the end 
node sends the packet directly, in expectation that the other node is there. 

If a response is received, the end node examines the received packet to see 
if the "on-Ethernet" bit is set (the bit is checked even if the first packet went 
to the designated router). If the bit is not set, no action is taken; if the bit is 
set, then the next packet can be sent directly, rather than by means of the 
designated router. 
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2.4.4.3 Area Routing on an Ethernet 

All nodes on an Ethernet need not be in the same area; more than one area 
can be configured on a single Ethernet. The areas on the same Ethernet are 
logically separate from each other. When two level 1 routing nodes on an 
Ethernet are configured in different areas, the nodes do not communicate 
directly with each other. Each level 1 router communicates with a level 2 
router in its own area, which sends the message to a level 2 router in the 
other area. The level 2 router that receives the message then transmits it 
to the second level 1 router. Area routing on an Ethernet is illustrated in 
Section A.6. 


2.4.5 Routers and End Nodes on Cl Data Links 

Nodes in a VAXcluster using a Cl data link can be configured as routers or 
end nodes. 


2.4.5.1 Cl End Nodes 

A two-node VAXcluster using a Cl data link can be configured using end 
nodes only, but at east one router is required if additional nodes are 
configured in the cluster. The Cl protocol does not include the multiaccess 
capabilities of the Ethernet protocol. 


2.4.5.2 Cl Routers 

One or more Cl routers are necessary if a VAXcluster consists of three or more 
nodes. Cl circuit devices are treated as though they were multipoint devices 
(like the DMP device) rather than as multiaccess devices such as the Ethernet 
circuit device. Although only one router is required in a cluster of more than 
two nodes, having more routers in the cluster environment increases the 
overall availability of the network within the cluster. 

If the VAXcluster configuration includes end nodes as well as routers, a 
backup, higher-cost circuit could be provided for each end node. This backup 
circuit could take over if the primary circuit connecting the end node to its 
router fails (see Section 3.7.6). 

Note that end nodes communicating through a router send all data through 
that router even though they are connected to the same Cl. The best 
performance and availability are achieved by defining all VAXcluster nodes as 
routers if the Cl is used as the datalink. 


2.4.6 Routing Concepts and Terms 

This section briefly explains routing concepts and defines those routing 
parameters that provide some control over network routing. Use of NCP 
commands to set these routing parameters is described in Chapter 3. A more 
detailed explanation of routing concepts and the routing algorithms for the 
routing layer can be found in the Introduction to DECnet manual. 

The following terms are used to describe DECnet routing and routing 
parameters: 

• Hop. The logical distance between two nodes is measured in hops. The 
distance between two adjacent nodes is one hop. 

• Path. A path is the route a packet takes from source to destination. 
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• Path length. The path length is the number of hops along a path between 
two nodes; it is the number of circuits a packet must travel across to 
reach its destination. The path length never exceeds a maximum number 
of hops, a value that the system manager sets relative to the size and 
configuration of each network. For an area network, the network manager 
should determine the maximum number of hops permitted within an area 
and between areas. 

• Cost. The cost is an integer value assigned to a circuit between two 
adjacent nodes. It is usually proportioned to transmission delay. Each 
circuit has a separate cost. In terms of the routing algorithm, packets are 
routed on paths with the least cost. Nodes on either end of a circuit can 
assign different costs to the same circuit. 

• Path cost. The path cost is the sum of the circuit costs along a path 
between two nodes. The path cost never exceeds a maximum cost value 
the network manager specifies for the network. For an area network, the 
network manager sets the maximum cost for a path within an area, and 
for a path between areas. 

• Reachable node. A reachable node is a destination node to which the 
Routing layer on the local node has a usable path; that is, the path does 
not exceed the values for maximum cost or hops between nodes specified 
in the executor database. For an area network, a reachable area is one 

to which the path does not exceed the values for maximum cost or hops 
between areas set in the executor database. 

• Maximum visits. The maximum number of nodes through which a 
packet can be routed before arriving at the destination node is referred 
to as the maximum number of visits the packet can make. If a packet 
exceeds the maximum number of visits, the packet is dropped. 


When configuring a network, the network manager establishes the routing 
parameters for circuit cost control and route-through control. These 
parameters allow you to control the path that data is likely to take when 
being transmitted through the network, and also to minimize congestion at 
particular nodes in the network. For most networks, the default values for 
these parameters are reasonable. 

As network manager, you must assign a circuit cost to every circuit that 
connects the local node with adjacent remote nodes. These costs serve as 
values that DECnet software uses to determine the path over which data is 
transmitted. When the node is up and running, you can dynamically change 
the cost of a circuit to a higher or lower value. Altering circuit costs can 
change packet routing paths and thereby affect the use and availability of 
network circuits and resources. 

Along with defining circuit costs, you should also consider the path lengths 
and total path cost for routing packets over the network. For routing 
purposes, DECnet software identifies the least costly path to each destination 
in the network. As network manager, you are responsible for defining both 
the maximum cost of all circuits and the maximum hops that a packet can 
take when routed to the destination node. If you are configuring an area 
network, you should define the maximum cost and hops for a path between 
nodes within your own area, and the maximum cost and hops for a path 
between level 2 routers in the whole network. 
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The Routing layer in each node of the network uses congestion-control 
algorithms to maintain an efficient level of routing throughput. In addition, as 
network manager, you can maintain indirect control over routing throughput 
by defining the maximum visits a packet can make before being received by 
the destination node. Packets that have exceeded this limit are discarded. 
This control prevents packets from looping endlessly through the network. 


2.4.7 Routing Messages 

Adjacent routing nodes exchange routing update messages. A routing update 
message is a packet that contains information about the cost and hops for 
each node in the network. In an area network, a level 1 router sends routing 
update messages about all nodes within its own area to adjacent routers in 
the area. Level 2 routers send routing update messages containing cost and 
hop information about all areas to adjacent level 2 routers in the network. 

Whenever this routing information changes (for instance, when a circuit 
goes down) new routing messages will be sent automatically. For example, 
if someone were to change the state of a circuit, rendering a remote node 
unreachable, this change would be reflected automatically in the routing 
update messages exchanged by the routing nodes. 


2.4.7.1 Segmented Routing Messages 

The number of nodes that Phase IV DECnet can support in a single-area 
network is increased to a maximum of 1023 from the limit of 256 for Phase 
III DECnet. This increase is due to changes in the routing update messages. 
In Phase III, a legal network was restricted in size to the number of nodes 
for which cost and hop information could be fit into a single routing update 
message. Furthermore, Phase III routers had to send complete updates 
containing information about all nodes, whether or not their reachability had 
changed. Phase IV allows segmented routing messages to be sent, that is, 
messages that contain only the information that has been changed. Phase IV 
also permits routing updates to be sent in multiple messages. Therefore, the 
size of the routing messages and the number of buffers required to receive 
them are reduced. 


2.4.7.2 Timing of Routing Message Transmissions 

The network manager can set a timer for transmission of routing messages, 
controlling the intervals at which nonconfiguration change routing updates 
are transmitted. The routing timer controls the frequency of transmission of 
these messages on non-Ethernet circuits. The broadcast routing timer controls 
their frequency for Ethernet circuits. Expiration of the broadcast routing timer 
causes the local node to send a multicast routing configuration message to all 
routers on the Ethernet. 


2.5 Logical Links 

DECnet uses a mechanism called a logical link to allow communication 
between processes running on either the same node or on separate nodes in 
the network. A logical link carries a stream (consisting of regular data and 
interrupt data) of full-duplex traffic between two user-level processes. Each 
logical link is a temporary data path that exists until one of the two processes 
terminates the connection. 
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As system manager, you can control various aspects of logical link operation 
on the local node. You can 

• Define the maximum number of logical links that can be active at the local 
node. If your node can also use an alias node address (which is common 
to some or all nodes in a VAXcluster), you can specify the maximum 
number of logical links that can use the alias for incoming and outgoing 
connections. Note that the upper limit on the number of logical links that 
your node can originate using the individual node address is reduced if 
your node also uses an alias. 

• Specify the number of packets that can be transmitted on a logical link 
before an acknowledgment is received (the pipeline quota). 

• Selectively disconnect active links on the local node while the network is 
running and verify that the links have been disconnected, by displaying 
information on the status of the links. 

Logical link activity related to the Network Services Protocol (NSP) is 
controlled by certain parameters that regulate the duration of NSP connect 
sequences and inactivity intervals, and the frequency with which NSP 
retransmits messages. The timers that affect this activity include 

• The incoming timer, which protects the local node against the overhead 
caused by a local process that does not respond to an inbound connection 
request within a specified interval 

• The outgoing timer, which protects the local node against the overhead 
caused by a connection request to a remote node that does not complete 
within a specified interval 

• The inactivity timer, which protects the user against a link that may be 
permanently unusable, by setting the frequency with which DECnet tests 
an inactive link 

You should normally use default values for the parameters which regulate 
the frequency of NSP message retransmission at the local node, unless you 
need to change the operating characteristics of a particular logical link. The 
retransmit time is affected by the estimated delay in round-trip transmission 
between the local node and the node with which it is communicating. The 
delay weight and delay factor parameters are used to calculate new values for 
this estimated delay. The retransmit factor parameter governs the number of 
times NSP will try to retransmit on a logical link. 


2.6 Objects 


Objects provide known general-purpose network services. An object is 
identified by object type, which is a discrete numeric identifier for either a 
user task or a DECnet program such as NML or FAL. The DECnet network 
software uses object type numbers to enable logical link communication using 
NSP. The system manager is responsible for supplying information for those 
objects, both user-defined and network objects, that can be used over the 
network. 

For VAX PSI network operations, you are responsible for identifying objects 
by name, and establishing command procedures to be initiated when 
incoming X.25 calls to the objects arrive. 
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2.6.1 DECnet-VAX Objects 

When setting up the network, you must supply information for two general 
kinds of DECnet-VAX objects: 

• Objects with a 0 object type. These objects are usually user-defined 
images for special-purpose applications. They are named when a user 
requests a connection. Objects in this category are defined in the DECnet- 
VAX configuration database as TASK (see Section 3.9.1). The object type 
number for all of these objects is 0. 

• Nonzero objects. Nonzero objects are known objects that provide specific 
network services such as FAL (file access) or NML (network management). 
They may also be user-defined tasks; these objects should be for user- 
supplied known services. Object type numbers for all nonzero objects 
range from 1 to 255. The number serves as a standard addressing 
mechanism across a heterogeneous network. For a complete list of 
network objects, refer to the VAX/VMS Network Control Program Reference 
Manual. 

The following DIGITAL-supplied objects are defined inside NETACP, by 
default, in the configuration database. Note that MAIL and PHONE are 
specific to VAX/VMS. 

• File access listener (FAL). FAL is an image that provides authorized access 
to the file system of a DECnet node on behalf of processes executing on 
any node in the network. FAL communicates with the initiating node by 
means of the Data Access Protocol (DAP). 

• Network management listener (NML). NML is an image that provides 
services such as gathering and reporting information about network status, 
zeroing line and node counters, and loading a standalone system image to 
a remote node. 

• Event logger (EVL). EVL is an image that logs significant events (locally or 
remotely) for a given network component. 

• Loopback mirror (MIRROR). MIRROR is an image that is used for 
particular forms of loopback testing. 

• DECnet Test Receiver (DTR). DTR is a DECnet test program that is 
used with the DECnet Test Sender (DTS) to test logical links. The DTS 
/DTR Utility is described in the DECnet Test Receiver/DECnet Test Sender 
Reference Manual. 

• MAIL. MAIL is an image that provides personal mail service for 
VAX/VMS nodes. 

• PHONE. PHONE is an image that allows you to have online 
"conversations" with users on VAX/VMS. 

• Host loader (HLD). HLD is an image that provides downline task-loading 
support for RSX-11S tasks. 

For every object that can be started by an inbound connection request, you 
must supply a command procedure unless either of the following conditions 
exists: 

• The object is one of the following DIGITAL-supplied command 
procedures: FAL, HLD, NML, EVL, DTR, MAIL, PHONE, MIRROR 
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• The object is defined as an image, through specification of objectname.EXE 
as the object file name. 

Rules for establishing and identifying command files for objects are given in 
Chapter 3. 

You can also specify privileges a user must have in order to connect to the 
object, and provide default access control information to be used for inbound 
connections to the object when no access control is specified by the remote 
node. Additionally, you can assign default proxy login access controls for the 
object. Refer to Section 2.10 for a discussion of access control information 
used for logical link connections and a description of proxy login access 
control. 


2.6.2 Objects Using the Cluster Alias Node Identifier 

If your node is in a VAXcluster that is using an alias node identifier, you have 
the option of specifying how the cluster alias node address is to be used in 
relation to incoming and outgoing connections for specific network objects. 

By default, all objects except PHONE are able to receive connect requests 
directed to the alias node identifier. For outgoing connections, the default is 
that only the MAIL object will be associated with the alias node address. If 
you send mail from a cluster node that uses the alias, the sender's address on 
the mail message will be the alias node identifier. 

The alias node address should not be specified for objects that require 
multiple incoming links, because an incoming link identified by the alias 
node address may be assigned to any of the nodes participating in the cluster 
alias node address. For example, PHONE should not use the alias node 
address, because it requires that all incoming links be directed to the same 
node in the cluster. Nontransparent tasks that have a mailbox and can receive 
multiple inbound connection requests should not be accessed using the alias 
node address (see Chapter 8). Also, objects whose resources are not available 
clusterwide should not be allowed to receive incoming connect requests 
addressed to the alias node address. 


2.6.3 Creating DECnet—VAX Network Server Processes 

On VAX/VMS, all DECnet objects run as processes. Unless a currently 
running process has declared itself to be a numbered network object or a 
named network object (with number 0), NETACP must invoke a process 
to receive the connect request. When the logical link request comes in, a 
standard procedure called NETSERVER.COM is run, which in turn causes 
NETSERVER.EXE to be executed. This program works in concert with 
NETACP to invoke the proper program for the requested object. Then, 
when the logical link is disconnected, the "object" program (such as FAL) 
terminates, but the process is not deleted. Instead, control returns to the 
NETSERVER.EXE program, which asks NETACP for another incoming logical 
link request to process. This cycle continues until NETSERVER is deleted 
after a specified time limit. The default is 5 minutes. To use a different 
default time limit, specify the logical name NETSERVER$TIMEOUT, using an 
equivalence string in the standard VAX/VMS "delta time" format: 

dddd hh:mm:ss.cc 
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The effect of NETSERVER is to reuse network server processes for more 
than one logical link request, eliminating the overhead of process creation 
for an often-used node. NETACP reuses a NETSERVER process only if the 
access control on the connect request matches that used to start the process 
originally. 

When NETACP creates a process to receive the connect request, the process 
runs like a batch job. The sequence is as follows: 

1 The process is logged in according to information found in the UAF. 

The key to this file is the username, which is part of the access control 
information. The process is successfully logged in only if the password 
from the access control string matches the password in the UAF record. 
(Refer to Section 2.10 for a discussion of DECnet access control.) 

2 DECnet-VAX automatically creates a log file in 
SYS$LOGIN:NETSERVER.LOG. Unlike the log file for a batch job, this 
log file is neither printed nor deleted. The log file is helpful for debugging 
your own network tasks. If NETSERVER.LOG cannot be created for any 
reason, the network job will continue running but will not produce any 
log file. 

3 The login command procedure indicated in the UAF for the process is 
executed. 

4 The process runs a command file to start the image that implements the 
DECnet object. The rules for locating this command file differ depending 
on whether or not the object has the number 0. 

Because NETSERVER.LOG files are not required for network server processes, 
you may explicitly inhibit all log files in your default nonprivileged DECnet 
account by setting the default directory for the account to a nonexistent 
directory. The effect of this action is to suppress all log files, while allowing 
network jobs to be run. 


2.6.4 Potential Causes of Network Process Failures 

If a logical link fails and the status information displayed is "network partner 
exited," this message indicates a problem in the remote network server 
process. To determine the details of the failure, consult the NETSERVER.LOG 
file at the remote node. Common reasons for failure are 

• Inability to log in because of failure to access the system login procedure, 
or the account login procedure or any files that it accesses. 

• Protection set on network procedures and images in SYS$SYSTEM, such 
as NETSERVER.COM or NETSERVER.EXE. 

• Attempted execution in your LOGIN.COM file of an interactive 
command that does not apply to network/batch jobs (for example, a 
SET TERMINAL/VT100 or SET TERMINAL/INQUIRE command). These 
commands should not be specified in your LOGIN.COM file unless they 
are preceded by IF F$MODE() .EQS. "INTERACTIVE". 

For example, in your LOGIN.COM file, use the following to prevent a logical 
link failure: 

$ IF F$MODE() .EQS. "INTERACTIVE" THEN - 
SET TERMINAL/VT100 
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Any failure to create NETSERVER.LOG will cause a network job to continue 
running, but without a log file. 


2.6.5 VAX PSI Objects 

The object component of VAX PSI contains records that identify the object, 
specify a command procedure that is initiated when the incoming call arrives, 
and specify account information for the incoming call. 

You must identify each VAX PSI object by a unique name. For each object, 
you must create a command procedure for starting the object that will be 
executed each time an incoming X.25 call to the object is received. Rules for 
establishing and identifying the command procedures are given in Chapter 3. 
For each object, you must also supply account information (consisting of 
a user name, password, and, optionally, an account name) to be used by 
incoming X.25 calls from remote DTEs. 


2.7 X.25 and X.29 Server Modules 

To handle calls coming in over a PSDN from remote DTEs and terminals, 
configure the X.25 and X.29 server modules, referred to as the X.25 and X.29 
call handlers, as required. The X.25 server module handles incoming calls 
that originated at a remote DTE; the X.29 server module handles incoming 
calls that originated at a remote terminal. Your local DECnet-VAX node can 
receive X.25 and X.29 calls if it is configured as any of the following: 

• A DTE connected directly to a PSDN (to be a DTE, a DECnet-VAX node 
must have VAX PSI software installed) 

• A multihost connector node that forwards calls between a PSDN and 
host node (to serve as a connector node, a DECnet-VAX node must be 
configured with VAX PSI software in multihost mode) 

• A host node that uses a connector node to send and receive X.25 and X.29 
calls (to be a host node, a DECnet-VAX node must be configured with 
VAX PSI Access software) 


2.7.1 Destination of Calls from a Remote DTE 

The configuration database for the server modules defines the processes that 
are the destinations for calls, so that incoming calls from a PSDN can be 
directed to the appropriate destination. If your node is serving as a DTE 
connected directly to a PSDN or indirectly as a host node using an X.25 
connector node, the destination is on the local node. If your node is serving 
as an X.25 connector node, the destination may be on one of the host nodes 
using the connector node. 

The server database specifies the maximum number of circuits the server 
module may have; that is, the maximum number of incoming and outgoing 
calls that all destinations can handle. 

When establishing the server configuration database, you must identify 
each destination by a unique alphanumeric name. You must also name the 
object activated when a particular destination accepts an incoming call, and 
assign priorities to all destinations that could handle the same incoming call. 
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Optionally, you can restrict the incoming calls a destination will handle to 
any combination of the following: 

• Calls to specified local DTE subaddresses 

• Calls from specified user groups (BCUGs and CUGs) 

• Calls from specified remote DTEs 

• Calls containing user data that matches a specified call value once a mask 
has been applied 

• Calls that have been redirected from another DTE 

• Calls received from a particular network 

• Calls containing particular values in the called address extension after a 
mask has been applied 

If your local node is serving as an X.25 connector node, you must identify in 
the X.25 server database the host node on which each destination is located. 

Chapter 3 describes how to use NCP commands to specify call handling 
parameters in the configuration database. 


2.7.2 Handling Incoming Calls at the Local DTE 

This section describes the process of handling incoming calls at the local DTE 
as it relates to network management. The VAX PSI X.25 Programmer's Guide 
describes the handling of incoming calls as it relates to programming PSI 
network tasks. 

Whenever a remote DTE attempts to communicate with your local DTE 
(that is, attempts to set up a virtual circuit), the remote DTE, the PSDN, and 
the local DTE provide information that identifies the user process that is 
the destination of the call. Remote DTE information passed with the call is 
optional; such information may include the remote DTE address, a local DTE 
subaddress, a closed user group (CUG) or bilateral closed user group (BCUG) 
name, and so on. VAX PSI at the local DTE uses this information, along with 
destination information defined in the configuration database at the local DTE 
for the server module and objects, to determine how to handle the incoming 
call. 

When an incoming call is received, VAX PSI constructs a network connect 
block (NCB) using the remote DTE address and other information that may 
be specified. VAX PSI then attempts to match the information in these fields 
with the information specified for destinations in the configuration database. 

If only one match is made, VAX PSI associates the incoming call with the 
object specified in the configuration database for this destination. If more 
than one match is made, VAX PSI chooses the destination with the highest 
priority. Then it associates the incoming call with the object specified for this 
destination (see Section 2.6.4). 

The object names the task that is to run as a result of the incoming call. 

(A command procedure associated with the object is activated when' the 
incoming call arrives; this user-written command procedure may activate 
a user program or an image.) Section 2.6 discusses objects and object 
parameters specified in the configuration database. 
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VAX PSI rejects the incoming call if (1) no match is made, and (2) a last- 
chance destination has not been specified. A last-chance destination is a 
destination with an associated object that handles all incoming calls for 
which a match cannot be found. The simplest last-chance destination is 
a destination that specifies the complete range of local DTE subaddresses, 
handles calls from all DTEs and all user groups, and ignores any incoming 
call-handling information in the user data field. It specifies no subaddress, 
no CUGs, no remote DTEs, and no local subaddresses. The last-chance 
destination must have the lowest priority of all the destinations. 


2.8 X.25 Access Module 

The X.25 access module provides a means for user processes on VAX/VMS 
host nodes to access remote nodes or terminals connected to a PSDN through 
a VAX/VMS node serving as a multihost connector node. The host node 
must be configured with VAX PSI Access software. The connector node must 
be configured with VAX PSI software in multihost mode. 

The X.25 access module identifies the connector node to which the local 
node is to be connected, the network the connector node can access, and, 
optionally, access control information. The DECnet-VAX host system with 
VAX PSI Access uses a DECnet link to connect to the connector node. VAX 
PSI Access software uses the link to transmit X.25/X.29 messages between 
the host and the connector node. 


2.9 Logging 

The network software logs significant events that occur during network 
operation. An event is defined as a network or system-specific occurrence for 
which the logging component maintains a record. A partial list of significant 
events includes 

• Circuit and node counter activity 

• Changes in circuit, line, and node states 

• Service requests (when a circuit or line is put in an automatic service state) 

• Passive loopback (when the executor is looping back test messages) 

• Routing performance and error counters (circuit, line, node, and data 
packet transmission) 

• Data transmission performance and error counters (when errors in data 
transmission occur) 

• Lost event reporting (when some number of events are not logged) 


This information can be useful for maintaining the network because it can 
be recorded continuously by the event logger. As system manager, you are 
responsible for controlling certain aspects of event logging. In particular, you 
can control source-related parameters (actual events to be logged, the source 
for these events, and the location at which these events will be logged) and 
sink-related parameters (the name of the logging component at the local node 
and its operational state). 
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For the most part, events are logged for the various DNA layers and for 
system-specific resources. Events are defined by class and type, in the format 
class.type. The class of an event identifies the layer or resource to which the 
event applies, and the type is the particular form of event within the class. 
For example, event 4.3 indicates oversized packet loss (type 3) for the Routing 
layer (class 4). Event classes and types are summarized in the VAX/VMS 
Network Control Program Reference Manual. 

The logging component is the device or process that records logging events. 
There are three logging components: 

• A logging console, which is generally a terminal or file that records 
events in user-readable form. If no logging console name is specified, the 
operator console (OPAO) will be used. 

• A logging file, in which events are recorded in binary format. Detailed 
information regarding the format can be obtained from the DNA Phase IV 
Network Management Functional Specification. There is no default logging 
file name. 

• A logging monitor, which is a program supplied by the system or user 
that receives and processes events. If a logging monitor is specified, events 
formatted in user-readable form are sent to the Operator Communication 
(OPCOM) facility; all network operator terminals (terminals enabled 
through specification of the DCL command REPLY/ENABLE=NETWORK) 
display these events. Also, if a logging monitor name is specified, events 
encoded in binary format are sent to the DECnet object specified by that 
name; detailed information regarding the format can be obtained from the 
DNA Phase IV Network Management Functional Specification. 

Both the logging console and the logging monitor can be used to display 
events at the operator console; however, the inherent flexibility of OPCOM 
and its ability to display messages at terminals being used for timesharing 
may make the logging monitor a more suitable choice for many sites. 

The source of an event can be an area, node, module, circuit, or line. Events 
can be logged at either the local node or a remote node; this node is called 

the sink node. 

At the local node, you can control the operational state of the logging sink. 
You must turn logging on before events can be logged to the sink, and off 
before the logging parameters for the sink can be cleared from the database. 
Specify the hold state to queue events for a specific logging sink. 


2.10 Network Access Control 

DECnet-VAX regulates access to the network on various levels, including 

• Routing initialization passwords for links connecting the local node to 
remote nodes 

• System-level access control for inbound logical link connections that result 
in a process being created 

• Node-level access control for inbound and outbound logical links 

• Proxy login access control for individual accounts 
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This section describes these levels of control as they relate to DECnet-VAX 
software operation, from the perspective of the system manager's need to 
establish control parameters through NCP. Use of specific NCP commands to 
accomplish access control is described in Chapter 3. 


2.10.1 Routing Initialization Passwords 

Whenever you turn on a circuit, your local node attempts to initialize with 
the DECnet software at the remote node connection for that circuit. As part 
of this initialization process, the remote node may require a password to 
complete the operation. The system manager can specify passwords when 
setting up the configuration database. 

In a Phase IV network, passwords are required when a Phase III node is 
initialized (see Section A.5.2.2), but are optional when a Phase IV node is 
initialized. Generally, passwords are used in initializing Phase IV nodes only 
when a system has dialup telephone lines used by the network. When a 
dialup node seeks a dynamic connection over a terminal line, the dialup node 
must supply a password, but the node receiving the login request will not 
send a password to the dialup node. 

Figure 2-4 illustrates a routing initialization sequence for the network 
example. When the circuit is turned on, nodes BOSTON and TRNTO 
initialize. On the local node, BOSTON, DECnet-VAX software retrieves 
the transmit password for remote node TRNTO and sends it to TRNTO upon 
request. On node TRNTO, DECnet-VAX verifies this password with the 
receive password specified for remote node BOSTON in its configuration 
database. Once the passwords are verified, the link is operational; that is, the 
circuit state makes the transition from ON-STARTING to ON. 

Figure 2-4 Routing Initialization Passwords 


TRNTO 


NCP>SET LINE DMC-0 STATE ON 



ZK-548-81 
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for the adjacent node, DECnet-VAX will accept anything the adjacent node 
may send. The adjacent node is still required to send the verification message. 


2.10.2 System-Level Access Control 

DECnet-VAX provides system-level access control over logical link 
connections. The network user on the initiating node may explicitly supply 
an access control string to control which account is used on the remote 
node. If, however, the initiating node does not supply explicit access control 
information, DECnet optionally provides default access control when sending 
the request to the remote node. It also optionally provides default access 
control for incoming logical links if the initiating node has not supplied access 
control information. 


2.10.2.1 Setting Access Control Information for Outbound Connects 

The system manager can specify default access control information for 
outbound connections. This enables the local node to send outbound logical 
link requests with default access control information when that information is 
not explicitly provided. The remote node stores the access control information 
in its configuration database. The default access control information can 
include privileged and nonprivileged names and passwords to be used in 
connecting to a particular remote node. 

The system manager at a node can specify a list of privileges required for 
connection to a particular object, such as NML. When the local node requests 
connection to an object for which privileges have been specified, it sends 
the default privileged access control string to the remote node. If the system 
manager does not specify privileges for an object, such as FAL, the object is 
accessible to all users. When the local node requests connection to this object, 
it sends the nonprivileged access control string. 


2.10.2.2 Sources of Access Control Information for Logical Link Connections 

Whenever a local DECnet node attempts to connect to a remote DECnet-VAX 
node by means of a logical link, system-level access control information is 
sent to the LOGINOUT image running in the context of a process on the 
remote node. Access control information can come from a number of sources: 


• The network user on the local node may explicitly supply an access 
control string. If this is the case, the remote node uses the access control 
information. 

• If the access control string is not explicitly supplied, the local node checks 
its object database against the privileges of the initiating process. If the 
object does not require privileges other than TMPMBX and NETMBX, the 
local node sends the default nonprivileged access control string from its 
node database to the remote node. 

• If the object requires privileges beyond TMPMBX and NETMBX, and the 
user process has the required privileges, the local node sends the default 
privileged access control string from its node database to the remote node. 

• If no access control string is supplied, the local node checks to see if proxy 
access is enabled at the participating nodes. If so, LOGINOUT checks the 
NETUAF.DAT file to determine whether a user should be logged in to a 
designated account rather than the nonprivileged account. (Proxy login 
access control is described in Section 2.10.5.) 
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• If none of the cases above is valid, the local node sends a "no" access 
control string. 

• When the remote node sees that no access control has been specified, 
it checks its object database. If the object database contains a default 
inbound access control string, the remote node uses that string. 

• If there is no default access control information in its object database, 
the remote node checks its node database for nonprivileged account 
information about the local node. If the information is there, the remote 
node uses the nonprivileged access control string. 

Finally, if none of these sources supplies the information, the connection fails. 


Note: In DECnet-VAX usage, nonprivileged means NETMBX and TMPMBX 
privileges only. NETMBX is the minimal requirement for any network 
activity. Privileged means any privileges in addition to NETMBX or 
TMPMBX. 

Figure 2-5 illustrates the local node's access control options for inbound 
connection requests. 

Figure 2-5 Access Control for Inbound Connections 


OUTBOUND CONNECTION 
(from local node) 


INBOUND CONNECTION 
(from local node) 



to remote 
node 


Regardless of the source, the remote node uses this information to determine 
whether a logical link can be established. The way this validation process 
works is important for both the system manager and network users. This 
section discusses access control in terms of network management. Chapter 8 
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discusses access control as it relates to user-level operations such as remote 
file access and task-to-task communication. 

Access control information is not used where the connection is to a program 
that has declared a name or object number and has started independently of 
DECnet. 

Access control information allows users on remote nodes to gain access to 
resources on the local node. The system manager must establish access 
control information in both the configuration database (for objects) and the 
UAF (for default network accounts) on the local node. Chapter 1 briefly 
describes the necessity for these default accounts. Chapter 5 explains how to 
create a default nonprivileged DECnet account. 

Whenever NETACP on the local node receives an inbound logical link 
connection request, it creates a process and starts the LOGINOUT image, 
which verifies the user's access rights by checking the UAF. When VAX/VMS 
starts a user process as a result of an inbound connection request, the 
privileges with which that process runs are determined by the UAF record 
associated with the access control information passed in the connection 
message. This function is almost identical to the one that occurs whenever a 
local user starts a batch job; the difference is that the resulting LOG file will 
be neither printed nor deleted. Section 2.6 discusses this process in detail. 


2.10.2.3 Network Security and Passwords 

You can maintain password security in a network environment by protecting 
the network configuration files from unauthorized access. The most 
convenient way to do this is to require SYSPRV to access these files. 

NML must have access to network configuration files. NML on the remote 
node accesses these files when it sees the NCP commands that access the 
permanent database (DEFINE, PURGE, LIST, and SET "component" ALL). 

Once you have set access control (as described in the previous section), users 
must have the privileges necessary to perform the following operations: 

• To modify the volatile database, NML users must have OPER privilege. 

• To specify the permanent database (using the DEFINE command) or to 
update the volatile database with all parameters from the permanent 
database (using the SET "component" ALL command), the user must have 
OPER privilege and WRITE access to all permanent database files. 

• To remove specific parameters from the permanent database (using the 
PURGE command) or to reset or remove all parameters from the volatile 
database (using the CLEAR "component" ALL command), the user must 
have OPER privilege and write access to all permanent database files. To 
clear counters, the user must have OPER privilege. 

• To start the network, a user must have ACNT, CMKRNL, SYSNAM, and 
DETACH privileges. 

To make these safeguards operational, you should avoid assigning privileges 
beyond those normally used. In particular, you should not give the default 
privileged account SYSPRV. These default accounts should be in their own 
group to avoid extending group access to other directories on the local node. 
Sensitive files and directories may be protected against world access by 
requiring explicit access control to reach them. 
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2.10.2.4 Inbound Default Access Control for Objects 

Another form of access control specific to network objects is default account 
information that is used by inbound connects from remote nodes that send 
no access control information. Because no access control information is 
supplied, the default information you specify for the object is used to allow 
the logical link connection to be made. One example of this is downline task 
loading. When SLD connects to HLD on the host node, default access control 
information specified for the HLD object is used. Refer to Chapter 4 for more 
information on downline task loading. 


2.10.3 Access Control for Remote Command Execution 

If you are requesting that an NCP command be executed at a remote node, 
you can supply an explicit access control string or default to access control 
information in the configuration database. To supply an explicit access control 
string, use either the standard VAX/VMS node specification (node"user 
password account"::) or specify this access control information as parameters 
in the NCP command to be executed at a remote node. 


2.10.4 Node-Level Access Control 

As system manager, you can regulate two forms of node-level access control 
for incoming and outgoing logical links. One form involves specifying the 
ACCESS parameter for a particular node in your volatile database, and the 
other involves specifying the DEFAULT ACCESS parameter in your executor 
database. 


When an incoming or outgoing logical link connection is attempted, the 
executor node first checks its volatile database for the ACCESS entry for the 
target node. If the entry exists, the executor uses it. 

Because it might not be feasible to include an ACCESS entry for every node 
in a large network, DECnet-VAX provides the DEFAULT ACCESS alternative 
If the logical link connection is attempted and there is no ACCESS entry for 
the remote node in the volatile database, the executor uses the DEFAULT 
ACCESS parameter value. 

Both commands accept the same set of parameter values, which are listed 
below. 


INCOMING 

OUTGOING 

BOTH 

NONE 


Allows logical link connections from the remote node, but does 
not allow the local node to initiate connections to the remote 
node. 

Allows the local node to initiate connections to the remote node, 
but does not allow connections from the remote node. 

Allows incoming and outgoing logical link connections. This is the 
default. 

Does not allow incoming or outgoing logical link connections to 
this node. 


If no entry is specified for the ACCESS or DEFAULT ACCESS parameters, 
the DEFAULT ACCESS parameter defaults to BOTH. 

Only those users with OPER privilege can bypass this access protection. 
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For each node, you can configure the privileged and nonprivileged accounts 
and passwords that constitute default access control information. This default 
access control information should match the system-level access control 
information established for the node (see Section 2.10.2). 

Another form of access control at the node level is the node checking that 
is performed before a system can dial in and form a dynamic asynchronous 
connection over a terminal line. For a description of security measures for 
dynamic asynchronous connections, see Section 2.10.6. 


2.10.5 Proxy Login Access Control 

Proxy login permits a user who is logged in at a remote node to be logged 
in automatically to a specific account at the local node, without having to 
supply any access control information. The remote user must have a proxy 
account on the local node that maps to a local user account. The remote user 
assumes the same file access rights as the local account and also receives the 
default privileges of the local account. The proxy login capability can be used 
to increase security, by minimizing the need to specify explicit access control 
strings in node specifications passed over the network or stored in command 
procedures. 

The procedure for establishing proxy accounts is summarized below, followed 
by a description of the means of controlling proxy login access over the 
network. 


2.10.5.1 Proxy Accounts 

Proxy accounts permit one or more users on a remote node to obtain access 
privileges on a node without having a private account on that node. The 
remote user can issue commands to access data that is accessible by the local 
account to which he has proxy access. 

The system manager controls the use of proxy accounts at the local 
node, using the Authorize Utility to create and modify the network user 
authorization file, NETUAF.DAT. NETUAF.DAT contains proxy login 
records, each of which maps a remote node name and user name (in the 
form NODE::USER) to the user name of a single local account. Each remote 
user can access only one local user account. For a summary description of 
proxy accounts and how to create them, see the VAX/VMS System Manager's 
Reference Manual. The Authorize Utility is described in the VAX/VMS 
Authorize Utility Reference Manual. 


2.10.5.2 Controlling Proxy Login Access 

If no access control string is supplied when the local node receives a request 
for initiation of an inbound connection, the local system checks to see if 
proxy access is enabled at the participating nodes. By default, both incoming 
and outgoing proxy login access is enabled for each node. If proxy access 
is enabled, LOGINOUT checks the NETUAF.DAT file to determine if the 
user should be logged in to a designated account rather than the default 
nonprivileged DECnet account. 

Proxy login access for the local node is controlled by the setting of the 
DEFAULT PROXY entry in the volatile database. DECnet-VAX has set 
this entry to permit proxy logins to be initiated by the local node or by 
the remote node; this is the recommended setting. The use of proxy logins 
can be restricted, however, through specification of the executor parameter 
DEFAULT PROXY in the configuration database. The possible proxy access 
options for the local node are defined below. 
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INCOMING 

OUTGOING 

BOTH 

NONE 


Allows proxy login access from the remote node to the local 
node. 

Allows the local node to initiate proxy login access to the remote 
node, but does not allow proxy login access from the remote 
node to the local node. 

Allows both incoming and outgoing proxy login access. This is 
the default and the recommended option. 

Does not allow incoming or outgoing proxy login access 
connections to the local node. 


Proxy login access to a specific network object is controlled by the value of 
the object parameter PROXY set in the configuration database. Defaults for 
each object are set in the database. Permitting proxy login access to an object 
is recommended only if the proxy access serves some useful purpose. For 
example, by default MAIL is set to prevent incoming proxy login, while FAL 
is set to allow both incoming and outgoing proxy login. 

Four options are available for the PROXY parameter for a network object: 


INCOMING 

OUTGOING 

BOTH 

NONE 


Allows proxy login to the object. 

Allows the object to initiate proxy login. 

Allows both incoming and outgoing proxy login access. This is 
the default option. 

Does not allow incoming or outgoing proxy login access. 


Note that there are advantages to disallowing incoming proxy access to an 
object (such as MAIL) that does not require it. Whenever possible, incoming 
connect requests are matched up with compatible existing NETSERVER 
processes, to avoid the overhead of unnecessary process creation. If a user 
on a remote node with outgoing proxy access sends a request to connect to 
an object with incoming proxy enabled on the local node, the connect request 
will only be matched with a NETSERVER process that was started by a 
previous request from the same user on the same node. This matching occurs 
because the proxy database is processed by LOGINOUT, not by NETACP. If 
the object disallows incoming proxy access, incoming connect requests will 
use default access control, with a higher probability of being matched with an 
existing NETSERVER process. 


2.10.6 Security for DDCMP Point-to-Point Connections 

If a remote node requests a connection over a DDCMP point-to-point circuit, 
the local node can avoid revealing its routing initialization password, while 
requiring that the remote node supply its password. This security measure is 
used to protect the password of the local node when a dialup node initiates 
an asynchonous connection to the local node. 

For example, a user at a system with a terminal line (such as a Micro VMS 
system) can dial in to another system (such as a VAX/VMS system in a 
VAXcluster) and initiate a dynamic connection, causing the terminal lines 
to be converted to asynchronous DDCMP communications lines for the 
duration of the telephone call. To prevent attempts at access by callers 
at unauthorized nodes, certain checks have been included in the dynamic 
configuration process. The dialup node must be the type of node (router or 
end node) expected by the local VAX/VMS node. When the dialup node 
attempts to initialize, it must supply a routing initialization password to 
the local node, but the local node does not send its password to the dialup 
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node. This preserves the security of the local node in case the dialup node 
is unauthorized. In addition, the connection has been configured to end 
automatically when the telephone is hung up. 
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Managing and Monitoring the Network 


This chapter explains how to use network management commands and 
parameters to configure, manage, and monitor network software. The 
management tools and components available to DECnet-VAX and VAX PSI 
users fall into 13 broad categories: 

• The configuration database 

• The Network Control Program (NCP) 

• The executor node and remote nodes 

• X.25 protocol modules 

• Circuits 

• Lines 

• Routing 

• Links 

• Objects 

• X.25 and X.29 server modules 

• X.25 access modules 

• Logging 

• Access control 


This chapter should provide enough information to build a network 
configuration database for your VAX/VMS operating system. It will also 
explain how to use most NCP commands at both the local node and remote 
nodes to modify parameters for the running network. See Chapter 5 for 
examples that use NCP commands to build databases for various network 
configurations. 

DECnet-VAX and VAX PSI network components and operating concepts are 
described in Chapter 2. Reference information on the operation of the NCP 
utility program and the complete syntax of NCP commands appear in the 
VAX/VMS Network Control Program Reference Manual. 


3.1 The DECnet—VAX Configuration Database 

The DECnet-VAX configuration database contains files that provide 
information about the local node, remote nodes, local physical lines, local 
circuits, local logging, and local objects. Each DECnet node in the network 
has a network database that supplies component and parameter information 
of this kind. To ensure successful node-to-node communication, each node 
has a configuration database that consists of the following databases: 

• A node database with a record for each node, including the local node 

• A circuit database with a record for each circuit known to the local node 
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• A line database with a record for each physical line known to the local 
node 

• A logging database with a record for each sink (logged events are sent to 
the sinks) 

In addition, NETACP provides a default object database with a record for 
each object known to the network, including objects (for example, FAL) that 
are defined when you bring up the local node. 

As system manager, you need to specify the nodes that can communicate 
with your node, the physical lines that connect the nodes, and the circuits 
associated with those lines. In some cases, this connection may include more 
than one line and circuit to the remote node. You also need to establish a 
variety of operational routing parameters for the local node to ensure proper 
network operation. 

To allow for communication between nodes, NETACP defines several network 
objects including NML, FAL, and TASK. 

To provide network management flexibility, the DECnet-VAX configuration 
database consists of two distinct databases, one volatile and one permanent. 
In addition, if VAX PSI is included in the network, a VAX PSI configuration 
database, consisting of a volatile database and a permanent database, exists at 
the local DTE (see Section 3.1.3). 


3.1.1 The Volatile Database 

The volatile copy of the DECnet-VAX configuration database is memory 
resident; it allows you to control the running network without modifying 
the permanent database. NCP provides commands for setting, clearing, and 
showing network component parameters for the volatile database. NCP also 
permits you to copy current information about remote nodes from the node 
database of another node into your volatile database. 

You can change parameters in the volatile database while the system is 
running; these changes, however, will be in effect only until you modify them 
again or until the network is shut down. NETACP uses parameters specified 
only in the volatile database. 


3.1.2 The Permanent Database 

The permanent copy of the DECnet-VAX configuration database provides 
the initial values for the volatile database. You access the permanent 
database whenever you use the ALL parameter with the SET command, 
as, for example, when you bring up the network. In effect, the permanent 
database allows you to load network parameters into the volatile database 
when you boot the system. You can also change parameters in the permanent 
database. 

You can use NCP commands to define, purge, and list network component 
parameters in the permanent database. You can also use NCP to copy current 
remote node entries into your permanent node database from the database of 
another node to which you have access. 

You can optionally use the NETCONFIG.COM procedure to configure 
automatically the permanent database for your node (see Chapter 5). 
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3.1.3 VAX PSI Configuration Database 

The VAX PSI configuration database contains files that provide information 
concerning the local DTE, local lines, virtual circuits, local modules, and 
local objects. Each PSI DTE that is connected to a PSDN has a database that 
supplies component and parameter information of this kind. For successful 
DTE-to-DTE communication, each DTE has a minimum configuration 
database that consists of the following databases: 

• A circuit database with a record for each permanent virtual circuit (PVC), 
if PVCs are in use 

• An object database with a record for each object 

• A line database with a record for each physical line to a PSDN 

• A module database with records for the PSDN(s), the DTE(s), groups, and 
destinations. 

The VAX PSI configuration is also stored in the DECnet-VAX configuration 
database. 

Just as with the DECnet-VAX configuration database, the VAX PSI 
configuration database consists of both a volatile and a permanent database. 

You can use NCP commands to configure the VAX PSI software at any time. 
STARTNET.COM sets the parameters in the volatile database every time you 
load the VAX PSI software (see Chapter 6). You can change parameters in 
the configuration database while VAX PSI is running. 


3.2 The Network Control Program 

The Network Control Program (NCP) is the vehicle for creating and 
modifying component parameters in the configuration database. In addition 
to the NCP command interface, DECnet-VAX users can write programs 
that communicate with NML through the Network Information and Control 
Exchange (NICE) protocol. For information concerning this interface, refer to 
the Phase IV Network Management Functional Specification. 

Most NCP commands allow you to modify either the volatile or the 
permanent database. NCP will access either database, depending on which 
command verb you use. For example, the following command accesses the 
permanent database to create or modify the address of* a remote node: 

NCP>DEFINE NODE 14 NAME DENVER 

To change the parameter in the volatile database, issue the command 

NCP>SET NODE 14 NAME DENVER 

The following list distinguishes command verbs by function and the database 
that they access. 


Function 

Volatile 

Permanent 

Creating/modifying parameters 

SET 

DEFINE 

Clearing parameters 

CLEAR 

PURGE 

Displaying parameters 

SHOW 

LIST 


Because the commands to access the volatile and permanent databases are 
similar, this chapter uses volatile database commands in all examples. 
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When configuring your network, you can use NCP either to build upon 
previously specified information or to change that information. Thus you 
do not have to delete all existing parameters and start over. For example, 
assume that you have identified a remote node address as 5. You can add 
node parameters for this record in the volatile database by using the SET 
NODE command. If you want to change the address of this node, you only 
need to specify a new address in the ADDRESS parameter of the SET NODE 
command. If you decide later that you want to remove any or all parameters 
for this node, then you could use the CLEAR NODE command. Commands 
to remove parameters exist for all network components. 

NCP commands operate on network components and their parameters. 

When issuing an NCP command, you must provide the command verb, the 
component name, and one or more parameters and/or qualifiers, as shown in 
the example below: 

$ RUN SYS$SYSTEM:NCP 

NCP>SET NODE 11 NAME BOSTON COUNTER TIMER 30 

NCP>SET KNOWN LOGGING STATE ON 


NCP> SET EXECUTOR^ STATION 

command component parameters 

Note that components consist of two types: singular (as with NODE 
BOSTON) and plural (as with KNOWN LOGGING). For example, you 
can display information about an individual node or all nodes (including the 
local node) in the network: 

NCP>SH0W NODE BOSTON COUNTERS 


NCP>SH0W KNOWN NODES COUNTERS 


Most NCP commands support both singular and plural component names. 

For a detailed description of NCP operation, the syntax of NCP commands, 
and examples of NCP command prompting, refer to the VAX/VMS Network 
Control Program Reference Manual 


3.3 Node Commands 

To establish your VAX/VMS operating system as a node in the DECnet 
network, you must build the node database entries for the DECnet-VAX 
configuration database. This section describes identification of the executor 
node and remote nodes, and the node parameters required to build an 
operational network node database. It also discusses updating your node 
database by copying current information about remote nodes from another 
node to which you have access. 


3-4 









Managing and Monitoring the Network 


3.3.1 Executor Node Commands 

NCP allows you to manage the operation and configuration of both your 
local node and remote nodes in the network. Generally, the NCP commands 
you will issue at your local node will be executed on that node. Occasionally, 
however, you may want to issue commands from the local node to be 
executed on adjacent or remote nodes. To this end, NCP incorporates the 
concept of an executor node. The executor node is simply the node on 
which NCP functions are actually performed, which in most cases will be the 
local node. To perform NCP functions on remote nodes, NCP supports two 
commands: SET EXECUTOR NODE and TELL. 

Note: For command descriptions in this manual, the executor node on non- 
Ethernet circuits is assumed to be the local node (BOSTON) unless 
otherwise specified. On Ethernet circuits, the executor node is usually 
ROBIN. 


3.3.1.1 SET EXECUTOR NODE Command 

The SET EXECUTOR NODE command sets the executor to the node at which 
you want the commands to execute. One use of this feature is to display 
information about the configuration database of the remote node. Figure 3-1 
illustrates this use of a remote executor node. 

As shown in Figure 3-1, you set the executor node by issuing the NCP 
command 

NCP>SET EXECUTOR NODE TRNTO 

NCP executes commands that you enter at your local node, BOSTON, at the 
remote executor node, TRNTO. The executor node interprets each command 
with its own network management software, and then performs the NCP 
function. Each command must be stated as if it were issued to NCP at the 
executor node. In this example, any information output that results from the 
execution of a command is displayed at node BOSTON. If the remote node 
is not running DECnet-VAX software, refer to the appropriate documentation 
for that node. 

To reset the executor to the local node, use the NCP command 

NCP>CLEAR EXECUTOR NODE 

The executor is always the local node when NCP is activated. It is possible 
for several users at one node to set their executor to different nodes. 

When you issue a SET EXECUTOR NODE command, you can either 
include specific access control information or use the default access control 
information. The level of privilege allowed at the remote executor node 
depends on the access control information specified. (Section 3.13 describes 
the access control format.) 

Note: When you clear the executor node, NCP communicates with NML as a 
shared image in the same process. Hence, clearing the executor node 
resets the executor's privileges to those of your current process—that is, 
the process running NCP. 
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Figure 3-1 Remote Command Execution 


BANGOR 


DENVER 



NYC 


BOSTON 

(Local Node) 


NCP>SET EXECUTOR NODE TRNTO 
NCP>SHOW KNOWN LINES \ 


NCP>CLEAR EXECUTOR NODE 
NCP> 


FROM BOSTON 
FROM TRNTO 


FROM BOSTON 

/K 18fir>-B4 


3.3.1.2 TELL Prefix 

As an alternative to using the SET EXECUTOR NODE command, you may 
want to execute only a single command at a remote node or you may want 
to temporarily override the current executor. In either case you can use the 
TELL prefix with an NCP command. For example, if you issue the following 
command at node BOSTON, NCP displays line information for all physical 
lines connected to node TRNTO: 

NCP>TELL TRNTO SHOW KNOWN LINES 
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Remote execution in this case applies only to the one command entered 
with the TELL prefix. Again, you can specify or default to access control 
information. 


3.3.2 Node Identification 

When configuring the network, you must identify in the executor 
configuration database the local node and all adjacent nodes connected to 
it by circuits. Identifying all nodes by name as well as address will permit 
you to reach any node by its name. This section describes node identification 
and discusses NCP parameters relevant to identifying nodes. 

Either the node address or the node name can serve as a node identifier 
(node-id). The node address is a decimal number assigned to the node in 
the configuration database. The address must be unique within the network. 
The node address may include as a prefix the area number, a decimal integer 
indicating the area in which the node is grouped. In the node address, the 
area number and node number are separated by a period, in the following 
format: 

area-number.node-number 

For example, if node 3 is in area 7, its node address is 7.3. The area number 
must be unique within the network and the node number must be unique 
within the area. If you do not specify an area number, the area number of 
the executor node is used. The default area number for the executor is area 
1. In multiple-area networks, it is recommended that you always specify the 
area number. 

A node name is an optional, unique alphanumeric string that contains up 
to six characters including at least one alphabetic character. It can be used 
interchangeably with the node address to identify a node. In the single¬ 
area network example in Chapter 1, the node name BOSTON and the node 
address 1.11 identify the same node. 

When defining remote nodes in the volatile database, use the SET NODE 
command to specify node names and node addresses. The command below 
associates the node name TRNTO with the node whose address is 1.5. 

NCP>SET NODE 5 NAME TRNTO 

To specify a node address for the local node, use the SET EXECUTOR 
command, as in the following example: 

NCP>SET EXECUTOR ADDRESS 11 

Then, use the following command to specify a node name for the local node: 

NCP>SET NODE 11 NAME BOSTON 

By issuing these commands, you have established a remote node (TRNTO) 
whose address is 1.5 and the local node (BOSTON) whose address is 1.11. 
You can then build upon this information to establish parameters for the 
various nodes. 

Before a node can be accessed by name, you must specify a node name to be 
associated with a node address. 
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3.3.2.1 


3.3.2.2 


Once you set the executor node's address in the volatile database, you cannot 
change it unless you turn off and restart the network. However, you can 
change any other node's address at any time. For example: 

NCP>SET NODE TRNTO ADDRESS 6 
NCP>SET NODE TRNTO ADDRESS 8 


Maximum Address Parameter 

The MAXIMUM ADDRESS parameter sets the highest address that the 
local node will recognize. Setting this parameter allows you to group node 
addresses in a predefined range, which minimizes the size of internal data 
structures and control mechanisms for DECnet-VAX software. For example, 
the command below sets the highest remote node address at 17. 

NCP>SET EXECUTOR MAXIMUM ADDRESS 17 


Local Node Identification Parameter 

In addition to defining a node name and address for the local node, you can 
also specify a descriptive quoted string of alphanumeric characters. NCP 
will display this string whenever you issue the SHOW EXECUTOR or LIST 
EXECUTOR command. Use the IDENTIFICATION parameter with the SET 
EXECUTOR command to specify this optional information, as shown in the 
command below. 

NCP>SET EXECUTOR IDENTIFICATION "VMS HOST SYSTEM" 

This command provides information that NCP displays whenever you use the 
SHOW EXECUTOR command to display executor node information, as in the 
following example: 

NCP>SH0W EXECUTOR CHARACTERISTICS 


Node Volatile Characteristics as of 14-JAN-1986 11:27:07 


Executor node 
Identification 
Management version 
Incoming timer 
Outgoing timer 
NSP version 
Maximum links 
Delay factor 
Delay weight 
Inactivity timer 
Retransmit factor 
Routing version 
Type 

Routing timer 
Broadcast routing timer 
Maximum address 
Maximum circuits 
Maximum cost 
Maximum hops 
Maximum visits 
Maximum area 
Max broadcast nonrouters 
Max broadcast routers 
Area maximum cost 
Area maximum hops 
Maximum buffers 
Buffer size 
Default access 
Pipeline quota 
Default proxy access 
Alias incoming 
Alias maximum links 
Alias Node 


-1.11 (BOSTON) 

= VMS HOST SYSTEM 
= V4.0.0 
= 45 
= 45 
= V4.0 
= 32 
= 80 
= 5 
= 60 
- 10 

= V2.0.0 
= routing IV 
= 600 
= 40 
= 255 
= 16 
= 1022 
= 15 
= 63 
= 63 
= 64 
= 32 
= 1022 
= 30 
= 100 
= 576 

= incoming and outgoing 
= 1200 

= incoming and outgoing 
= Enabled 
= 32 

-1.10 (CLUSTR) 
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3.3.2.3 Using and Removing Node Names and Addresses 

Once you have specified a node name and address, you can use them 
interchangeably whenever you need to specify a node-id. The local DECnet- 
VAX software translates the node names into node addresses. In the single¬ 
area network example, the NCP commands below perform identical functions. 

NCP>SH0W NODE 5 CHARACTERISTICS 


NCP>SH0W NODE TRNTO CHARACTERISTICS 


To remove a remote node name from the volatile database, use the CLEAR 
NODE command. The following command removes the association between 
TRNTO and node 5: 

NCP>CLEAR NODE 5 NAME TRNTO 

To remove a remote node address from the volatile database, you must 
remove all parameters for the node. You can also remove addresses for all 
known nodes other than the local node, as in the following example: 

NCP>CLEAR NODE TRNTO ALL 


NCP>CLEAR KNOWN NODES ALL 

Once all parameters for a component are removed from the volatile database, 
the component is no longer recognized by the network. 

Note: To change the ADDRESS or BUFFER SIZE parameter for your node, you 
must first turn off the executor. Refer to Section 3.3.5.2 and Chapter 6 for 
information on changing the local node's operational state. 


3.3.3 Identifying Cluster Nodes 

For many network operations it is convenient to be able to treat nodes within 
a homogeneous VAXcluster as though they were a single node in a DECnet 
network. This can be accomplished by establishing an alias node identifier for 
the cluster. The alias node identifier can be specified as either a unique node 
address or a corresponding node name. Any member node can elect to use 
this special node identifier as an alias while retaining its own unique node 
identification. Use of the cluster alias node identifier is optional. 

The management of a cluster alias node involves three primary decisions: 

1 Will an individual node participate in the use of a cluster alias node 
identifier? 

2 If a node participates, does it want to receive inbound connect requests 
targeted to the cluster alias address? 

3 For any object defined on a participating node, should the object's logical 
links appear to have originated from the cluster alias node and should the 
object be able to receive incoming connect requests that are directed to the 
cluster alias address? 
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To establish an alias node identifier for a local node, use the SET EXECUTOR 
or DEFINE EXECUTOR command with the ALIAS NODE parameter, 
described in Section 3.3.3.1. To enable incoming requests to the cluster alias 
node address, use the ALIAS INCOMING parameter of the SET EXECUTOR 
or DEFINE EXECUTOR command, as described in Section 3.3.3.2. 

The SET OBJECT command allows you to associate specific objects with 
the cluster alias node identifier, by means of the ALIAS OUTGOING 
parameter. You can also use the ALIAS INCOMING parameter to permit 
specific objects to receive incoming connect requests sent to the cluster alias 
address. Section 3.9.1 describes how to identify DECnet-VAX objects. 


3.3.3.1 Setting an Alias Node Identifier for the Executor 

You establish an alias node identifier for the local node using the SET 
EXECUTOR command with the ALIAS NODE parameter. When the local 
node includes an alias node identifier in its database, it can be accessed by 
either the cluster alias or its individual node name or node address. 

The alias node identifier can be either a node address or node name. Before 
a node name can be established as a cluster alias, the node name must be 
defined in the database, and associated with a node address representing the 
whole VAXcluster, by means of the SET NODE or DEFINE NODE command. 
For example, the following command associates the node name CLUSTR with 
the address 2.13: 

NCP>DEFINE NODE 2.13 NAME CLUSTR 

The name CLUSTR can then be established as the alias node identifier for the 
local node using the following command: 

NCP>DEFINE EXECUTOR ALIAS NODE CLUSTR 

By issuing these commands, you establish a node (CLUSTR) whose address 
is 2.13. This is the cluster alias node. Its address and name appear in the 
database like those of all other nodes. From the viewpoint of any node in the 
network outside the cluster, address 2.13, which is named CLUSTR, appears 
to be a real DECnet node that can participate in two-way communication. 
This cluster alias acts as a single node identifier that all participating nodes in 
the cluster can use to communicate with other nodes in the DECnet network. 


3.3.3.2 Enabling Aliases for Nodes in a Cluster 

When you manage the cluster alias node, you must decide whether 
participating nodes will accept incoming connect requests directed toward 
the cluster alias node identifier. You indicate this decision by specifying 
the ALIAS INCOMING parameter of the SET EXECUTOR or DEFINE 
EXECUTOR command. The ALIAS INCOMING parameter must be either 
enabled or disabled. To permit the node to accept incoming connect requests 
directed to the cluster alias node identifier, specify the ENABLED option. 
Otherwise, specify the DISABLED option to avoid receiving incoming connect 
requests directed to the cluster alias node identifier. 

The following command prevents the local node from receiving incoming 
connect requests directed to the alias node identifier. 

NCP>DEFINE EXECUTOR ALIAS INCOMING DISABLED 

By default, the ALIAS INCOMING parameter is enabled for a node if an alias 
node identifier has been defined for the node. 
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3.3.4 Ethernet Addresses of Nodes 

Nodes on Ethernet lines are identified by unique Ethernet addresses. A 
message can be sent to one, several, or all nodes on an Ethernet line 
simultaneously, depending on the Ethernet address used. You do not 
normally have to specify the Ethernet address of an individual node in order 
to configure your network; the software at the node sets its own Ethernet 
address. You need to know the Ethernet address of a node for service 
functions (such as downline load, circuit loopback test, and configurator 
operations) but not for normal network operations. 


3.3.4.1 Format of Ethernet Addresses 

An Ethernet address is 48 bits in length. Ethernet addresses are represented 
by six pairs of hexadecimal digits (6 bytes), separated by hyphens (for 
example, AA-01-23-45-67-FF). The bytes are displayed from left to right in 
the order in which they are transmitted; bits within each byte are transmitted 
from right to left. In the example, byte AA is transmitted first; byte FF is 
transmitted last. 

Xerox Corporation assigns a block of addresses to a producer of Ethernet 
interfaces upon application. Thus every manufacturer has a unique set of 
addresses to use. Normally, one address out of the assigned block of physical 
addresses is permanently associated with each interface (usually in a read¬ 
only memory). This address is known as the Ethernet hardware address of 
the interface. 

DIGITAL's interface to Ethernet (for example, the DEUNA, DELUA, or 
DEQNA controller) can set a different address to be used by the interface; this 
address is known as the Ethernet physical address. 

On powerup of the node, the Ethernet physical address is set to the hardware 
address. When DECnet starts an Ethernet line (for example, UNA-0), it 
causes the DEUNA connected to that line to set its physical address to be in 
the range of DIGITAL Ethernet addresses. Specifically, the DEUNA constructs 
the Ethernet physical address by appending the 16-bit executor node address 
to a constant 32-bit number (AA-00-04-00) within the block of Ethernet 
addresses assigned to DIGITAL. 


r 


32 bits 


v 


16 bits 



Constant within 
Ethernet block assigned 
to DIGITAL 


DECnet node 
address 


ZK-1215-82 


An example is a Phase IV routing node with DECnet address 1.182 (decimal), 
which would be set to an Ethernet physical address of AA-00-04-00-B6-04. 
Because the DEUNA at the node constructs its own physical address, users 
normally do not need to manipulate Ethernet addresses directly. 

Once the Ethernet physical address has been set to its new value, it is reset to 
its original hardware address value only under the following circumstances: 
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• When a reset is issued to the DEUNA (for example, when the machine 
power is shut off) 

• When the state of the Ethernet line is set to OFF 

The Ethernet physical address of a node includes the number of the area 
in which the node resides. The area number is represented by the most 
significant 6 bits of the 16-bit DECnet node address, while the number of 
the node within the area is indicated by the least significant 10 bits of the 
node address (see Section 2.4.2). Therefore, changing the number of an area 
involves changing the Ethernet physical address of each node in that area. 

If an existing network is not divided into areas, the default area number 
1 is stored in the DECnet node address of each node. Conversion of an 
existing network to a multiple-area network may involve modification of the 
area number in the executor node address. During the conversion process 
(described in Section A.4), the network is shut down, the executor node 
address in the configuration database is modified to include the new area 
number, and the network is turned back on. When DECnet is restarted, it 
causes the DEUNA at the executor node to reset its Ethernet physical address. 

However, if a non-DECnet communications application (such as a LAT 
terminal server) is connected to the same Ethernet as the executor node whose 
area number is being modified, the Ethernet address of the executor used by 
the application cannot be changed while the interface to the application 
remains allocated. Thus the application should be stopped when DECnet is 
shut down and restarted after DECnet is turned back on. 


3.3.4.2 Determining the Ethernet Physical Address of a Node 

You can determine the Ethernet physical address of a node as follows: 

• Convert the Phase IV node address (in the format area-number.node- 
number, as described in Section 3.7.2) to its decimal equivalent, using the 
conversion algorithm 

(area-number * 1024) + node-number 

• Convert the decimal node address to its hexadecimal equivalent, reversing 
the order of the bytes to form the hexadecimal node address 

• Incorporate the hexadecimal node address in the format 

AA--00--04--00--hexnodeaddress 


For example, to determine the Ethernet physical address of a node whose 
node address is 63.171, calculate the following: 

(63 * 1024) + 171 = 64683 decimal = FCAB hexadecimal 

Therefore the Ethernet physical address of the node is 

AA-00-04-00-AB-FC 

You can display the Ethernet physical address of a node by specifying the 
following command: 

NCP>SH0W EXECUTOR STATUS 

The resulting display contains the Ethernet physical address of the executor, 
as shown below. 

Physical address = AA-00-04-00-AB-FC 
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3.3.4.3 Ethernet Physical and Multicast Addresses 

An Ethernet address can be a physical address of a single node or a multicast 
address, depending on the value of the low-order bit of the first byte of 
the address (this bit is transmitted first). The two types of node address are 
physical and multicast addresses. 

The Ethernet physical address is the unique address of a single node on 
any Ethernet (as described previously). The least significant bit of the first 
byte of an Ethernet physical address is 0. (For example, in physical address 
AA-00-04-00-FC-00, byte AA in binary is 1010 1010 and the value of the 
low-order bit is 0.) 

The Ethernet multicast address is a multidestination address of one or more 
nodes on a given Ethernet. The least significant bit of the first byte of a 
multicast address is 1. (For example, in the multicast address AB-22-22-22- 
22-22, byte AB in binary is 1010 1011 and the value of the low-order bit is 
1.) A multicast address can be either of the following: 

• Multicast group address. An address assigned to any number of nodes; 
this address can be used to send a message to all nodes in the group in a 
single transmission. The number of different groups that can be formed 
equals the maximum number of multicast group addresses that can be 
assigned. 

• Broadcast address. A single multicast address (specifically, FF-FF-FF- 
FF-FF-FF) that can be used to transmit a message to all nodes on a 
given Ethernet. (Note that the broadcast address should be used only for 
messages to be acted upon by all nodes on the Ethernet, since all nodes 
must process them.) 


3.3.4.4 Values of DIGITAL Ethernet Physical and Multicast Addresses 

DIGITAL physical addresses are in the range AA-00-00-00-00-00 through 
AA-00-04-FF-FF-FF. Multicast addresses assigned for use in cross-company 
communications are shown below. 


Value 

Meaning 

FF-FF-FF-FF-FF-FF 

Broadcast 

CF-00-00-00-00-00 

Loopback assistance 


DIGITAL multicast addresses assigned to be received by other DIGITAL nodes 
on the same Ethernet are shown below. 


Value 

Meaning 

AB—00—00—01-00-00 

Dump/load assistance 

AB—00—00—02—00—00 

Remote console 

AB-00-00-03-00-00 

All Phase IV routers 

A B—00—00—04-00—00 

All Phase IV end nodes 

AB—00—00—05—00—00 
through 

AB—00—03—FF—FF—FF 

Reserved for future use 

A B—00—04—00—00—00 

For use by DIGITAL customers for their own 

through 

AB—00—04—FF—FF—FF 

applications 
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DECnet always sets up the DEUNA at each node to receive messages sent to 
any address in the above list of DIGITAL multicast addresses. For information 
on sending messages to Ethernet multicast addresses, refer to the VAX/VMS 
I/O User's Reference Manual: Part II. 


3.3.5 Node Parameters 

To establish information used to control various aspects of the local node's 
operation within the network, you must specify the SET EXECUTOR 
command parameter ADDRESS, and you should specify MAXIMUM 
ADDRESS, BUFFER SIZE, and TYPE (you may be able to use a default 
value for the node type). In addition, you may wish to specify names, access 
control information, and node counter event logging information for any or 
all of the nodes. If a remote node can be loaded downline, you can specify a 
number of default parameters to be used locally to perform a downline load 
or upline dump operation. Table 3-1 lists all node parameters by function 
and indicates whether they apply to local or remote nodes or to both. 


Table 3-1 Node Parameters and Their Functions 


Local Remote 

Parameters According to Function Node Node 

Node identification 

ADDRESS node-address X X 

ALIAS NODE X 

IDENTIFICATION id-string X 

NAME node-name X X 

Loop node identification 

CIRCUIT circuit-id X 

Counter timing for node counter logging events 

COUNTER TIMER seconds X X 


Local node state 

STATE X 

ON 
OFF 

RESTRICTED 

SHUT 

Access control 

ACCESS X 

INCOMING 
OUTGOING 
BOTH 
NONE 

DEFAULT ACCESS X 

INCOMING 
OUTGOING 
BOTH 
NONE 
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Table 3-1 (Cont.) Node Parameters and Their Functions 


Local Remote 

Parameters According to Function Node Node 

DEFAULT PROXY X 

INCOMING 
OUTGOING 
BOTH 
NONE 

NONPRIVILEGED X X 

ACCOUNT account 
PASSWORD password 
USER user-id 

PRIVILEGED X X 

ACCOUNT account 
PASSWORD password 
USER user-id 


Downline loading 

CPU cpu-type X 

DIAGNOSTIC FILE file-spec X 

HARDWARE ADDRESS E-address X 

HOST node-id X 

LOAD FILE file-spec X 

SECONDARY LOADER file-spec X 

SERVICE CIRCUIT circuit-id X 

SERVICE DEVICE device-type X 

SERVICE PASSWORD hex-password X 

SOFTWARE IDENTIFICATION software-id X 

SOFTWARE TYPE type X 

TERTIARY LOADER file-spec X 

Upline dumping 

DUMP ADDRESS number X 

DUMP COUNT number X 

DUMP FILE number X 

Routing initialization passwords 

RECEIVE PASSWORD password X 

TRANSMIT PASSWORD X 

DDCMP circuit connection control 

INBOUND node-type X 

Data link control 

BUFFER SIZE number X 

MAXIMUM ADDRESS number X 

MAXIMUM BUFFERS number X 

MAXIMUM CIRCUITS number X 
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Table 3—1 (Cont.) Node Parameters and Their Functions 



Local 

Remote 

Parameters According to Function 

Node 

Node 


Logical link control 


ALIAS MAXIMUM LINKS number 

X 

DELAY FACTOR number 

X 

DELAY WEIGHT number 

X 

INACTIVITY TIMER seconds 

X 

INCOMING TIMER number 

X 

MAXIMUM LINKS number 

X 

OUTGOING TIMER seconds 

X 

PIPELINE QUOTA quota 

X 

RETRANSMIT FACTOR number 

X 

SEGMENT BUFFER SIZE 

X 

Routing control 

ALIAS INCOMING option 

X 

AREA MAXIMUM COST number 

X 

AREA MAXIMUM HOPS number 

X 

BROADCAST ROUTING TIMER seconds 

X 

MAXIMUM AREA number 

X 

MAXIMUM BROADCAST NONROUTERS number 

X 

MAXIMUM BROADCAST ROUTERS number 

X 

MAXIMUM COST number 

X 

MAXIMUM HOPS number 

X 

MAXIMUM VISITS number 

X 

ROUTING TIMER seconds 

X 

TYPE node-type 

X 

Incoming X.25 call control 

SUBADDRESSES range 

X 


You can specify parameters common to both the local node and remote nodes 
in one of two ways: use either the SET EXECUTOR or SET NODE command 
with the local node name or address to establish or modify parameters for the 
local node, or use the SET NODE command to establish or modify parameters 
for a remote node. 

When using either the SET EXECUTOR or SET NODE command to establish 
or modify parameters for the local node, be sure to avoid using, in the same 
command, parameters listed only under the Local Node column and those 
listed under both the Local Node and Remote Node columns in Table 3-1. If 
you mix these parameters in a single command, you will receive an "invalid 
grouping error" message. For example, the following commands are valid: 

NCP>SET EXECUTOR ADDRESS 11 
NCP>SET NODE 11 NAME BOSTON 
NCP>SET NODE 15 SERVICE CIRCUIT DMC-1 - 
_ RECEIVE PASSWORD RSXNODE 

The first command specifies a node address for the local node. The second 
command specifies a node name for the node whose address is 1.11, which in 
this case is the local node. The third command specifies parameters for node 
1.15. Note that this command contains parameters for both remote and 
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adjacent nodes. The command below, however, is invalid because it mixes 
parameters. 

NCP>SET EXECUTOR ADDRESS 11 NAME BOSTON 

'/.NCP-I-NMLRSP, listener response - Invalid parameter grouping, Address 

The CLEAR NODE command clears parameters for either the local or remote 
nodes. The CLEAR EXECUTOR command clears local node parameters 
common to both local and remote nodes. You cannot clear the local node 
parameters BUFFER SIZE and STATE from the volatile database. You 
can, however, purge them from the permanent database with the PURGE 
EXECUTOR command. You can use this same command to remove local 
node parameters common to both local and remote nodes from the permanent 
database. 

Once the local node's state is set to ON, you cannot change the ADDRESS or 
BUFFER SIZE parameters for the local node. 


3.3.5.1 Data Link Control 

Several local node parameters regulate various aspects of physical line 
operation. Specify the size of NSP receive buffers and transmit buffers 
(segment buffers), the number of buffers used to transmit on all circuits, 
and the number of circuits that the local node can use as DECnet-VAX 
communication lines. NCP provides four parameters for this purpose: 
BUFFER SIZE, SEGMENT BUFFER SIZE, MAXIMUM BUFFERS, and 
MAXIMUM CIRCUITS. You should be careful to set the values for these 
parameters to a reasonable level, or system performance might suffer. The 
parameters all have reasonable default values. 

For X.25 data links, the node parameters do not directly affect physical line 
operation. 

Setting Buffer Sizes 

To specify the maximum size (in bytes) of NSP receive buffers, use the 
BUFFER SIZE parameter. For example, the following command sets the size 
of all receive buffers for the executor node to 576 bytes: 

NCP>SET EXECUTOR BUFFER SIZE 576 

This parameter also controls the maximum segment size of all NSP messages 
that the local node can receive and forward. The buffer size value that you 
select will be used for all lines. You cannot use the BUFFER SIZE parameter 
to select individual values for individual lines. You can, however, use the 
BUFFER SIZE parameter in the SET LINE command to override the BUFFER 
SIZE value set in the executor for specific logical links on a line, such as a 
particular Ethernet line (see Section 3.6.2.2). 

The default BUFFER SIZE value is equal to the SEGMENT BUFFER SIZE if 
specified; otherwise the default size is 576 bytes. At a minimum, the buffer 
size must be 192 bytes. Refer to Chapter 5 and to the Network Services 
Functional Specification for more information in this area. 

You should consider a number of things when selecting the buffer size value. 

• These buffers require nonpaged memory pool. 

• The SYSGEN parameter LRPSIZE should be set to the executor buffer 
size. In addition, the parameter LRPCOUNT should be at least as large as 
the total number of all receive buffers on all lines, plus twice the number 
of circuits. 
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• Faster lines perform better with large buffers and large user messages that 
reduce the processor load. (The smaller the segments, the more messages 
are processed.) 

• Lines that are error prone (for example, telephone lines) should use 
small buffers (256 bytes) to reduce both the probability and the cost of 
retransmissions. 

The procedure for changing buffer sizes is described below. 

Note: It is strongly recommended that you use the same buffer size for all nodes 
in your network. Otherwise, nodes with smaller buffer sizes will drop 
packets when you attempt to route through them. 

Changing Buffer Sizes 

You can change the size of the buffers on all nodes without bringing down 
the entire network by performing a two-pass conversion process involving a 
second parameter, the SEGMENT BUFFER SIZE, as well as the BUFFER SIZE 
parameter. The conversion process requires only that you set the local node 
to the OFF state while changing the buffer size. 

The maximum size of the transmit buffer is specified in the SEGMENT 
BUFFER SIZE parameter. For example, the following command sets the 
maximum size of a transmit buffer to 576 bytes. 

NCP>SET EXECUTOR SEGMENT BUFFER SIZE 576 

The maximum size of the receive buffer is specified in the BUFFER SIZE 
parameter. The command below sets the maximum size of the receive buffer 
to 576 bytes. 

NCP>SET EXECUTOR BUFFER SIZE 576 

The SEGMENT BUFFER SIZE normally has the same value as the BUFFER 
SIZE, but may be set to less in order to perform the buffer size conversion 
process. The default value of the SEGMENT BUFFER SIZE is equal to the 
BUFFER SIZE if specified; otherwise the default size is 576 bytes. 

The steps in the conversion depend on whether you are increasing or 
decreasing the size of the buffers. To increase the size of the buffers, perform 
the following conversion: 

1 As the first step, reset the value of the BUFFER SIZE parameter at each 
node to the larger size, permitting each node to receive a larger message. 

2 As the second step, reset the value of the SEGMENT BUFFER SIZE 
parameter at each node to the larger size, permitting each node to transmit 
a larger message. 

This two-step process ensures that all nodes are able to receive and forward 
larger messages before any node is able to transmit a larger message. 

To decrease the size of the buffers, perform the following conversion: 

1 In the first pass, reset the value of the SEGMENT BUFFER SIZE parameter 
at each node to the smaller size, decreasing the size message that each 
node can transmit. 

2 In the second pass, reset the value of the BUFFER SIZE parameter at each 
node to the smaller size, decreasing the size message all nodes can receive. 


3-18 






Managing and Monitoring the Network 


This process ensures that the size of messages that can be transmitted across 
the network is decreased before the size of the buffers that receive and 
forward messages is decreased. 

An example of the conversion process involves increasing the size of messages 
that can be transmitted and received over the network from 576 bytes to 1000 
bytes. First, cause the following command to be executed at each node in the 
network: 

NCP>SET EXECUTOR BUFFER SIZE 1000 

Then cause the following command to be executed at each node in the 
network: 

NCP>SET EXECUTOR SEGMENT BUFFER SIZE 1000 

Each node will first be able to receive and forward 1000-byte messages, and 
then will be able to transmit them. 

Maximum Number of Buffers 

To specify the maximum number of buffers for the transmit buffer pool, use 
the MAXIMUM BUFFERS parameter. The value that you assign determines 
the size of internal data structures for DECnet-VAX software. For example, 
this command sets the maximum number of buffers to 20: 

NCP>SET EXECUTOR MAXIMUM BUFFERS 20 

If you do not specify a value for this parameter, DECnet-VAX will provide 
a default value of 100. Thus you do not have to specify a value unless 
you want to limit the amount of nonpaged pool used by DECnet-VAX. For 
most operations, DECnet-VAX will allocate only as many buffers as it needs 
(even if you specify a greater number than the amount needed), and will not 
allocate more than the number of buffers that you specify. 

Maximum Number of Circuits 

To specify the maximum number of circuits that the user can identify in 
the volatile database, use the MAXIMUM CIRCUITS parameter. This value 
determines the size of internal data structures for DECnet-VAX software. For 
example, the following command establishes an upper limit of 3 circuits that 
the local node can use: 

NCP>SET EXECUTOR MAXIMUM CIRCUITS 3 

The default value for this parameter is 16. 

If the local node is connected to an Ethernet circuit, the value of the 
MAXIMUM CIRCUITS parameter cannot be changed while the executor 
and the Ethernet circuit are in the ON state. 
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3.3.5.2 Operational State of the Local Node 

Use the STATE parameter in conjunction with the SET EXECUTOR command 
to exercise control of the operational state of the local node. There are four 
states associated with this parameter: 

OFF Allows no new logical links to be created, terminates existing 

links, and stops route-through traffic. The NETACP process 
exits. 

Allows new logical links to be created. The ON state is the 
normal operational state allowing route-through traffic. 

Allows no new logical links from other nodes, yet does not 
inhibit route-through. 

Similar to RESTRICTED. However, once all logical links are 
terminated, the local node goes to the OFF state. 

Any network user with the OPER privilege may initiate or confirm a logical 
link connection even though the local node is in the RESTRICTED or SHUT 
state. Thus a system manager can use NCP and NML when the network is in 
either of these states. 

Chapter 6 discusses local node states in terms of controlling the operation of 
the local node, and thus the network as a whole. 

Note: You should never use the DEFINE EXECUTOR STATE OFF command for 
the permanent database because this command would cause the network 
to shut down immediately after being started. 


ON 

RESTRICTED 

SHUT 


3.3.6 Copying Node Databases 

You can update your node database by copying current information about 
remote nodes from the configuration database of any node to which you 
have access. Use the COPY KNOWN NODES command to copy the volatile 
or permanent node database entries from a remote node to either or both 
the volatile and permanent node databases on your node. If you specify the 
WITH CLEAR or WITH PURGE qualifier on the COPY command, the local 
node database to which the information is to be copied is cleared or purged 
before the information is copied. Only the executor node characteristics and 
the name and address of the remote node are retained when the database is 
cleared or purged before a copy operation. 

The COPY KNOWN NODES command permits you to update your existing 
node database to reflect current data on remote nodes without having to shut 
down your node. If your network is large, the COPY command provides you 
with a means of keeping up with frequent changes in the composition of the 
network. For example, one node on an Ethernet may serve as the master, 
keeping in its node database current information on all remote nodes that can 
be accessed over the network. Then, as other nodes come up on the same 
Ethernet, they can obtain the latest version of the node database by copying 
it from the master node. 

If you did not specify any remote node entries when you configured your 
node, you can use the COPY command at any time to obtain the remote 
node entries that indicate the nodes to which you have access. If you want 
to copy the node database from a remote node which is not defined in your 
volatile database, you can specify the node's address in the COPY command; 
execution of the copy operation will cause the name and address of the node 
to be defined in your database. 
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COPY KNOWN NODES cannot be used to copy a subset of a node database. 


3.3.6.1 COPY Command Parameters and Qualifiers 

The COPY KNOWN NODES command causes the names and addresses 
of remote nodes to be copied from a remote database to the local node 
database or databases you specify. The FROM node-id parameter in the 
COPY command specifies the remote node from which the node database 
information is to be copied. 

You can include explicit access control information in the node-id field, or 
default to a proxy or DECnet account on the remote node, as appropriate. 
This command copies remote node data from node BOSTON on which user 
BROWN has an account with the password PASS 123: 

NCP>C0PY KNOWN NODES FROM B0ST0N"BR0WN PASS123" 

To indicate which node database at the remote node is to be copied, specify 
the USING VOLATILE or USING PERMANENT qualifier. If you do not 
specify the USING qualifier, the default value is USING VOLATILE. 

You can indicate the local node database to which the information is to be 
copied by specifying the TO qualifier. The local node database can be the 
volatile or permanent database, or both the volatile and permanent databases. 
In the following command, the volatile database at node BANGOR is to be 
copied to both the volatile and permanent databases at the local node: 

NCP>C0PY KNOWN NODES FROM BANGOR USING VOLATILE TO BOTH 

If you do not specify the TO qualifier, the local database defaults to 
VOLATILE. 

To clear or purge the local database before the copy operation is performed, 
specify the WITH CLEAR or WITH PURGE qualifier in the COPY command. 
The WITH CLEAR qualifier is appropriate if the local database is volatile; 
the WITH PURGE qualifier, if it is permanent. Specify either WITH CLEAR 
or WITH PURGE if both the volatile and permanent databases are to be 
cleared. (In practice, you can specify either value of the WITH qualifier to 
clear or purge either or both of the local databases.) The following command 
indicates that the permanent node database at the local node is to be purged 
before the remote node data from node BANGOR is copied to the local 
database: 

NCP>C0PY KNOWN NODES FROM BANGOR USING PERMANENT - 
_T0 PERMANENT WITH PURGE 


3.3.6.2 Clearing and Purging the Local Node Database 

During a copy operation, if the volatile database is to be cleared, the entries 
for the executor node and any loop nodes are not cleared. If the permanent 
database is to be purged, however, the entry for the executor node is purged. 
Therefore, before the purge occurs, the copy operation causes the executor 
node characteristics to be saved: a LIST EXECUTOR CHARACTERISTICS 
command is executed and the executor characteristics are stored. After the 
purge is executed, the executor characteristics are reinserted in the local node 
database. 

In addition, the local node must retain the name and address of the remote 
node from which it is to copy the data. Before the clear or purge operation 
is performed, the name and address of the remote node are saved. This 
information is reinserted in the local node database after the clear or purge 
operation is completed. Thus, to purge your database without purging your 
executor database, use the COPY KNOWN NODES command with the WITH 
PURGE qualifier. 
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Note that an error will result if the executor or remote node is not defined in 
the local node database. 

If an error occurs during execution of the LIST EXECUTOR 
CHARACTERISTICS command, the purge will be aborted. After the LIST 
operation has been performed, purging will continue even if errors are 
encountered. 

Clearing or purging the local database as part of a copy operation is 
recommended. If a clear or purge operation is not performed before the 
remote node data is copied, conflicts can occur between original node entries 
in the local database and node entries being copied from the remote node 
database. A node must be identified uniquely, by one name and one address. 
A conflict exists when the entries being copied on an existing database would 
cause one node address to be associated with two node names or two node 
addresses with one node name. When such a conflict occurs during the 
copy operation, the original node entry is not updated and an informational 
message is displayed. For example, if the local node database identified node 
A with address 3.1 and node B with address 3.3, an attempt to copy an 
entry that defines node A with address 3.3 would fail, and an informational 
message would be issued. 


3.3.6.3 Copying the Node Database from a Remote Node 

Entering a COPY KNOWN NODES command causes the following steps to 
be performed: 

• If you indicate that the volatile node database at the remote node is to 
be copied (by specifying the USING VOLATILE qualifier in the COPY 
command), a SHOW KNOWN NODES command is executed at the 
remote node. If you indicate the permanent node database is to be copied 
(by specifying the USING PERMANENT qualifier), a LIST KNOWN 
NODES command is executed at the remote node. 

• The COPY operation extracts remote node names and addresses from data 
returned by the SHOW or LIST command. 

• For each node name and address extracted, a SET or DEFINE NODE 
command is executed on the appropriate local node database. If you 
indicate in the COPY command that the information is to be copied to the 
volatile database, the following command is executed for each entry: 

SET NODE ADDRESS address NAME name 

If you indicate the information goes to both local node databases, both 
SET NODE and DEFINE NODE commands are executed for each remote 
node entry. When the COPY operation receives the name and address of 
the local node, no SET or DEFINE command is performed. 

When the name and address of the remote node from which the data is being 
copied is returned, the entry will indicate that it is the executor node. When 
the remote node is defined in the local database, however, it will not be listed 
as an executor node. Loop node names listed in the node database at the 
remote node will not be defined in the local database. 

Once the COPY operation has begun defining the remote nodes, it continues 
trying to define the nodes despite any errors it may encounter. It will issue 
informational messages for errors in individual node entries. 
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3.3.6.4 


Example of Copying Remote Node Data 

The following example illustrates the use of the COPY command to copy 
remote node entries from the permanent node database at node ROBIN to 
the permanent node database at node LARK without purging the local node 
database. In this example, node LARK has not defined the executor node or 
remote node ROBIN in its database; therefore, informational messages are 
displayed. Note that the copy operation is not performed for nodes A and C, 
because of a conflict between existing and updated addresses for these nodes. 
Informational messages are issued for the entries for nodes A and C. (In the 
example below, only the node entries resulting from the LIST commands are 
displayed.) 

To determine the node entries on the permanent node database at the local 
node, enter the following command, which causes the node entries to be 
displayed. Note that in this example the executor is not defined. 

NCP>LIST KNOWN NODES 

Remote node =2.1 (C) 

Remote node =2.3 (A) 

You can determine the node entries in the permanent node database at 
remote node ROBIN (whose address is 2.20) by specifying the command 
below, which causes the node entries to be displayed. You can reach node 
ROBIN by specifying its address in the NCP command, even though the node 
is not listed by name in the local node database. 

NCP>TELL 2.20 LIST KNOWN NODES 

Executor node =2.20 (ROBIN) 

Remote node =2.1 (A) 

Remote node = 2.2 (B) 

Remote node = 2.3 (C) 

To perform the copy operation, enter the following COPY command. The 
informational messages generated during the copy operation will be displayed 
on your screen directly under the COPY command. Note that remote node 
entries successfully copied to the local node database (such as node B) are not 
displayed under the COPY command. 

NCP>C0PY KNOWN NODES FROM 2.20 USING PERMANENT 
7.NCP-I-NMLRSP, listener response - Unrecognized component, Node 
'/.NCP-I-EXEABO, Executor characteristics not defined. 

'/.NCP-I-NMLRSP, listener response - Unrecognized component, Node 
'/.NCP-I-REMABO, Remote node not defined. 

y.NCP-I-NMLRSP , listener response - Invalid parameter value. Address 
Remote node = 2.1 (C) 

NODE 2.1 NAME A 

'/,NCP-I-NMLRSP, listener response - Invalid parameter value, Address 
Remote node = 2.3 (A) 

NODE 2.3 NAME C 


To determine the final results of the copy operation, enter the LIST KNOWN 
NODES command at your node to obtain the following display of node 
entries. 


ncp>list known nodes 


Remote node 
Remote node 
Remote node 
Remote node 


2.1 (C) 

2.2 (B) 

2.3 (A) 

2.20 (ROBIN) 
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3.3.7 Node Counters 


DECnet software automatically collects certain statistics for nodes in the 
network. These statistics are known as node counters. Such information may 
include the number of connects sent and received, the number of messages 
sent and received, and the number of packets lost. This information may be 
useful either alone or in conjunction with logging information to evaluate 
the performance of a given node. The network counter summary in the 
VAX/VMS Network Control Program Reference Manual describes the complete 
list of node counters. Refer to Section 2.9 for a discussion of logging. 

You can use NCP to regulate how often counters are logged and when they 
are zeroed. To do so, you can use the SET EXECUTOR or the SET NODE 
command with the COUNTER TIMER parameter. For example, the following 
command causes a node counter logging event to take place every 600 
seconds for the local node: 

NCP>SET EXECUTOR COUNTER TIMER 600 

The counters are then zeroed. Similarly, the following command specifies 
that counters for remote node TRNTO are to be logged at the local node 
every 600 seconds: 

NCP>SET NODE TRNTO COUNTER TIMER 600 

Note that these counters are maintained on the local node. To clear the 
COUNTER TIMER parameter, use the CLEAR EXECUTOR or CLEAR NODE 
command along with this parameter. 

You can display node counter statistics at any time while the network is 
running by using the SHOW NODE COUNTERS command. 

In addition, at any point when the network software is running, you can 
zero node counters for a given remote node, the local node, or for all known 
nodes. Use any of the following commands to zero node counters: 

NCP>ZER0 EXECUTOR COUNTERS 
NCP>ZER0 NODE BOSTON COUNTERS 
NCP>ZER0 KNOWN NODES COUNTERS 


3.4 X.25 Protocol Module Commands 

The X25-PROTOCOL module implements the X.25 level 3 protocol, which 
controls the transmission of data packets. This module structures control 
and user data into packets, sequences these packets for transmission, and 
establishes, maintains, and clears X.25 virtual circuits. This module also 
associates PSDNs, local DTE addresses, and optionally group names, with 
this controlling information. 

Use separate SET MODULE X25-PROTOCOL commands to specify a 
network, a DTE, and a group. 
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3.4.1 Network Identification 

Use the NETWORK qualifier to identify a network (that connects to a PSDN). 
The network name must be unique both on this database and any VAX 
X25-ACCESS databases. 

You must specify a profile as a parameter to the NETWORK qualifier. The 
profile is a file that gives maximum, minimum and default values for PSDN 
parameters. The profile also gives the facilities of the PSDN, such as FAST 
SELECT. 

The network profile is set up as part of the FCNS (Field Configurable 
Network Software) procedure, when VAX PSI is first matched with a 
particular PSDN. For further details, refer to the VAX PSI documentation 
set. 

The following command associates with the X25-PROTOCOL module the 
network TELENET 1, which has the profile TELENET: 

NCP>SET MODULE X25-PR0T0C0L NETWORK TELENET1 PROFILE TELENET 


3.4.2 Local DTE Identification 

Use the DTE qualifier followed by a NETWORK parameter to identify a local 
DTE and the network to which it is connected. For example, 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 NETWORK TELENET1 ... 

specifies a DTE which has the address 123789456 in network TELENET1. 

If you only have one network set up, you can omit the NETWORK parameter, 
because this network will be taken as the default. If you have more than one 
network set up, you must specify the network to which the DTE belongs. 

Refer to the VAX PSI Public Network Information Cards for DTE address 
formats. 


3.4.2.1 Operational State of DTE 

The STATE parameter specifies one of three operational states for each DTE. 

OFF Prevents use of the DTE and clears all existing virtual circuits. 

ON Allows normal use of the DTE. 

SHUT Prevents use of the DTE for any new activity, but allows existing virtual 
circuits to complete their operation. Once all circuits have been cleared, 
the DTE returns to the OFF state. 

The following command allows normal use of the DTE: 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 STATE ON ... 

The ON and SHUT states have substates; for a complete list of states, 
substates, and their transitions, refer to the VAX/VMS Network Control 
Program Reference Manual. The STATE parameter is optional. If it is not 
specified, the state is set to ON. 
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3.4.2.2 Line Identification 

The LINE parameter identifies the line associated with each DTE. Each DTE 
must have a unique line. Line identification takes the following format: 

dev-c[-u] 

dev Is a device name 

c Is a decimal number designating the device's hardware controller 

u Is a decimal unit or line number included if the device is a multiple unit line 
controller 

(Section 3.6.1 describes line identification.) 

Note that the unit number is optional for a DUP, DPV, or DMF. The 
command below identifies the line KMX-0-0 associated with DTE 123789456: 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 NET TELENET1 - 
LINE KMX-0-0 ... 

Use the SET LINE command to specify parameters for this line. 

The LINE parameter is mandatory when you specify a DTE for the first time. 


3.4.2.3 Channel Identification 

The CHANNELS parameter associates a set of logical channels to be used 
for outgoing calls with each DTE. Outgoing calls are all calls that originate 
from your DTE. Specify one or more logical channel numbers (LCNs) as a 
list. Separate multiple LCNs with hyphens to indicate ranges, and commas to 
indicate individual numbers. For example, the following command indicates 
that 20 is the first LCN, counting down from 20 to 10, then 3, and finally 9: 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 - 
_ CHANNELS 20-10,3,9 ... 

Specify a value in the range 1 to 4095 for each number in the range. 

The values you specify are those supplied by the PSDN authorities at 
subscription time. 


3.4.2.4 Maximum Circuits 

The MAXIMUM CIRCUITS parameter specifies the maximum number of 
circuits that each DTE can handle. For example, the following command 
specifies that the DTE 123789456 can handle a maximum of 200 circuits: 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 - 
MAXIMUM CIRCUITS 200... 

The MAXIMUM CIRCUITS parameter is optional and, by default, the 
maximum is 255. 

When you specify a DTE for the first time, this parameter indicates the size 
of the control area allocated from nonpaged pool. Thus, you cannot increase 
this value while the software is running. However, you can decrease the 
value and increase it again, provided that you do not specify a value larger 
than the original set. If this value is larger than required, nonpaged pool will 
be wasted. 
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3.4.2.5 INTERFACE Parameter 

The INTERFACE parameter specifies whether VAX PSI operates as a DTE, 
DCE, or automatically selects the correct interface (DTE or DCE). 

For example, the following command specifies that VAX PSI will operate as a 
DCE: 

NCP>SET MODULE X25-PR0T0C0L DTE INTERFACE DCE 

This parameter is of use only with the ISO8208 network profile. See also 
Section 3.4.8. 


3.4.3 Data Packet Control 

The transmission of data packets over an X.25 virtual circuit is determined by 
the size of the packet and the window. 


3.4.3.1 Packet Size 

The MAXIMUM DATA parameter specifies the maximum size of packets for 
all X.25 virtual circuits. The following command sets the maximum packet 
size to 128 bytes: 

NCP>SET MODULE X25-PR0T0C0L DTE ... MAXIMUM DATA 128 ... 

The packet size must always be at least 5 bytes smaller than the maximum 
size of the frame on a line (see Section 3.6.5). If the value in the PSI$_ 
NCB_PKTSIZE field of the network connect block (NCB) is greater than 
the value specified using the MAXIMUM DATA parameter, the MAXIMUM 
DATA value is used. 

The DEFAULT DATA parameter specifies a default packet size for all X.25 
virtual circuits. For example, the command below sets the default packet size 
to 64 bytes: 

NCP>SET MODULE X25-PROTOCOL DTE ... DEFAULT DATA 64 ... 

The default packet size must always be less than or equal to the maximum 
packet size. If the PSI$_NCB_PKTSIZE field of the NCB is not specified, the 
default packet size is used. The value must be a power of 2 in the range 16 
to 4096. 

The MAXIMUM DATA and DEFAULT DATA parameters are optional 
and take the network value by default; otherwise they must be set to the 
values specified in your PSDN subscription. See the VAX PSI Public Network 
Information Cards for the network values of these parameters. 


3.4.3.2 Window Size 

The MAXIMUM WINDOW parameter specifies the maximum window size 
for all X.25 virtual circuits. The value for this parameter will be the maximum 
number of packets for which outstanding acknowledgments are allowed. The 
command below sets the maximum window size to 3. 

NCP>SET MODULE X25-PR0T0C0L DTE ... MAXIMUM WINDOW 3 ... 

If the value in the PSI$_NCB_WINSIZE field of the NCB is greater than the 
value specified using the MAXIMUM WINDOW parameter, the MAXIMUM 
WINDOW value is used. 
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The DEFAULT WINDOW parameter specifies a default window size for 
all X.25 virtual circuits. For example, the command below sets the default 
window size to 2. 

NCP>SET MODULE X25-PR0T0C0L DTE ... DEFAULT WINDOW 2 ... 

The default window size must always be less than or equal to the maximum 
window size. If the PSI$_NCB_WINSIZE field of the NCB is not specified, 
the default window size is used. 

Specify values in the range 1 to 7 (unless extended sequence numbering is 
used on the PSDN, in which case the range is 1 to 127). The values must 
agree with your PSDN subscription. 

The MAXIMUM WINDOW and DEFAULT WINDOW parameters are optional 
and, by default, take the network value. See the VAX PSI Public Network 
Information Cards for the network values of these parameters. 


3.4.4 Call Request Packet Control 

Use the CALL TIMER parameter to control call setup. This timer starts to run 
when a request to set up a virtual circuit is transmitted; if it expires before 
a response has been received, the request will be cleared. In the command 
below, the request to set up a virtual circuit is cleared if no response has been 
received within 10 seconds. 

NCP>SET MODULE X25-PROTOCOL DTE ... CALL TIMER 10 ... 

Specify a value in the range 1 to 255. 

The CALL TIMER parameter is optional and, by default, takes the network 
value. See the VAX PSI Public Network Information Cards for the network 
value of this parameter. 


3.4.5 Clear Request Packet Control 

Two parameters control transmission of clear request packets over SVCs: 
CLEAR TIMER and MAXIMUM CLEARS. 

Use the CLEAR TIMER parameter to control how often clear request packets 
are retransmitted if not acknowledged. The following command sets the 
retransmission frequency to 20 seconds: 

NCP>SET MODULE X25-PR0T0C0L DTE ... CLEAR TIMER 20 ... 

Specify a value in the range 1 to 255. 

Use the MAXIMUM CLEARS parameter to specify the maximum number of 
times a clear request packet is retransmitted over the circuit. For example, 
the following command indicates that if a clear request is not acknowledged 
within 20 seconds, the request is retransmitted, and that this operation is to 
be performed a maximum of 8 times: 

NCP>SET MODULE X25-PR0T0C0L DTE ... CLEAR TIMER 20 - 
_ MAXIMUM CLEARS 8 ... 

The circuit is assumed to be cleared if the clear request is still not 
acknowledged by this time. 

Specify a value in the range 1 to 255. 
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The CLEAR TIMER and MAXIMUM CLEARS parameters are optional 
and take the network value by default. See the VAX PSI Public Network 
Information Cards for the network values of these parameters. 


3.4.6 Reset Control 

Two parameters control transmission of reset packets over SVCs and PVCs: 
RESET TIMER and MAXIMUM RESETS. 

Use the RESET TIMER parameter to control how often reset packets are 
retransmitted if not acknowledged. For example, the following command sets 
the retransmission frequency to 10 seconds: 

NCP>SET MODULE X25-PROTOCOL DTE ... RESET TIMER 10 ... 

Specify a value in the range 1 to 255. 

Use the MAXIMUM RESETS parameter to specify the maximum number of 
times a reset is retransmitted to the DCE. The command below indicates that 
if a reset is not acknowledged within 10 seconds, the reset is retransmitted, 
and that this operation is to be performed a maximum of 8 times: 

NCP>SET MODULE X25-PROTOCOL DTE ... RESET TIMER 10 - 
_ MAXIMUM RESETS 8 ... 

The circuit is cleared if the reset is still not acknowledged by this time. 
Specify a value in the range 1 to 255. 

The RESET TIMER and MAXIMUM RESETS parameters are optional and take 
the network value by default. See the VAX PSI Public Network Information 
Cards for the network values of these parameters. 


3.4.7 Restart Control 


Two parameters control transmission of restart packets over the data link to 
the DCE: RESTART TIMER and MAXIMUM RESTARTS. Use the RESTART 
TIMER to control how often restart packets are retransmitted. For example, 
the command below sets the retransmission frequency to 20 seconds. 

NCP>SET MODULE X25-PR0T0C0L DTE ... RESTART TIMER 20 ... 

Specify a value in the range 1 to 255. 

Use the MAXIMUM RESTARTS parameter to specify the maximum number 
of times a restart is retransmitted to the DCE. The command below specifies 
that a restart is to be retransmitted every 20 seconds, and that this operation 
is to be performed a maximum number of 10 times. 

NCP>SET MODULE X25-PROTOCOL DTE ... RESTART TIMER 20 - 
_ MAXIMUM RESTARTS 10 ... 

Specify a value in the range 1 to 255. 

The RESTART TIMER and MAXIMUM RESTARTS parameters are optional 
and take the network value by default. See the VAX PSI Public Network 
Information Cards for the network values of these parameters. 
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3.4.8 ISO Networks 


There are two parameters provided for use with an IS 8208 packet switching 
network. (IS 8208 is the International Standards Organization's definition of 
the CCITT X.25 recommendations.) 

The two parameters are INTERFACE and INTERRUPT TIMER. INTERFACE 
allows you to specify that your VAX PSI system acts in one of three ways: as 
a DTE, as a DCE, or automatically as either a DTE or DCE (parameter value 
NEGOTIATED). Refer to Section 3.4.2.5 for an example of specifying the 
INTERFACE parameter. 

INTERRUPT TIMER controls how long an interrupt may remain unconfirmed. 
If the interrupt is not confirmed within this time, the circuit is reset. The 
following command sets the interrupt timer to 150 seconds. 

NCP>SET MODULE X25-PR0T0C0L DTE ... INTERRUPT TIMER 150 


3.4.9 Group Identification 

If you are a member of either a closed user group (CUG) or bilateral closed 
user group (BCUG), always identify the group with the GROUP qualifier. 
Each group should have a unique name, which is a string 2 to 16 characters 
long. The following commands show a series of group specifications: 

NCP> SET MODULE X25-PROTOCOL GROUP ESECUG ... 

NCP> SET MODULE X25-PR0T0C0L GROUP DECCUG ... 

NCP> SET MODULE X25-PR0T0C0L GROUP BASINGSTOKE ... 


The local DTE, the group type, and the group number should be associated 
with each group. 


3.4.9.1 Local DTE Identification 

Use the DTE parameter to specify the address of the DTE that is associated 
with the group name, and the NETWORK parameter to identify the network 
to which the DTE belongs. For example: 

NCP>SET MODULE X25-PR0T0C0L GROUP ESECUG - 
DTE 123789456 NETWORK PSS1 ... 

The DTE parameter is mandatory when you specify a group for the first time. 
Note that once you set parameters for a group, you cannot change them 
except by clearing the group and setting it up again. 


3.4.9.2 Group Number 

Use the NUMBER parameter to specify the number that identifies your group. 
These numbers are allocated by the PSDN at subscription time. For example: 

NCP>SET MODULE X25-PR0T0C0L GROUP ESECUG NUMBER 12 ... 

The NUMBER parameter is mandatory when you specify a group for the first 
time. 
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3.4.9.3 Group Type 

If you are a member of a BCUG, use the TYPE BILATERAL parameter to 
specify this group type. For example: 

NCP>SET MODULE X25-PROTOCOL GROUP DECCUG TYPE BILATERAL ... 

If the group is a CUG, omit this parameter. 


3.4.10 X.25 Protocol Module Counters 

VAX PSI automatically maintains certain statistics for the X25-PROTOCOL 
module in the network. These statistics are known as protocol module 
counters. They may include the number of bytes, data blocks, calls, and fast 
selects sent and received; the number of active channels; the number of resets 
sent, received, or initiated by the network; and the number of restarts. These 
statistics are useful in monitoring the activity of the component. A complete 
list of protocol module counters is given in the VAX/VMS Network Control 
Program Reference Manual 


3.5 Circuit Commands 

The four classes of circuits that DECnet-VAX supports are DDCMP, Cl, 
Ethernet, and X.25 circuits. Using NCP commands, you must identify all 
DECnet circuits connected to the local node and all permanent virtual circuits 
connected to local DTEs, and specify parameters that affect the operation of 
the circuits. This section describes circuit identification and discusses using 
NCP commands to specify circuit parameters. 


3.5.1 Circuit Identification 

As with nodes, circuits must also have unique identifiers. DECnet circuits and 
X.25 circuits are not identified in the same way. 


3.5.1.1 DDCMP Circuit Identification 

For VAX/VMS, DDCMP circuit identification and line identification takes one 
of the following formats: 

dev-c 
dev-c-u 
dev-c.t 
dev-c-u.t 

dev Is a device name. (Refer to the VAX/VMS Network Control Program 
Reference Manual for a complete list of mnemonic device names.) 

c Is a decimal number (0 or a positive integer) that designates the hardware 
controller for the device. 

u Is a decimal unit or circuit number (0 or a positive integer) that is included 
only if there is more than one unit associated with the controller. 

t Is a decimal number (0 or a positive integer) that identifies a tributary on 
a multipoint circuit. This is a logical tributary number, not to be confused 
with the tributary address that is used to poll the tributary. 

Note: Circuit devices that are similar in operation are referred to by the same 
mnemonic. 
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DDCMP Point-to-Point Addressing 

The following command specifies a synchronous point-to-point circuit. The 
command identifies the DMC (or DMR) circuit device and controller number 
0 . 

NCP>SET CIRCUIT DMC-0 STATE ON 

The following command specifies an asynchronous point-to-point circuit. The 
command identifies the DZ11 asynchronous circuit device by the mnemonic 
TT, and specifies controller number 0 and unit number 0 (that is, TTAO). 

NCP>SET CIRCUIT TT-0-0 STATE ON 

Dynamic asynchronous DDCMP circuit names are supplied automatically 
when a dynamic connection is established. Note that you must load the 
asynchronous driver NODRIVER before establishing a dynamic connection. 

VAX/VMS maps network management circuit names to system-specific circuit 
names (for example, DMC-4 maps to XMEO). Network management circuit 
names provide network-wide circuit identification independent of individual 
operating system conventions. 

DDCMP Multipoint Tributary Addressing 

The command below identifies the DMP circuit device, controller number 0, 
and logical tributary 1. 

NCP>SET CIRCUIT DMP-0.1 STATE ON 

Use the SET CIRCUIT command to turn on the DMP circuit device as a 
multipoint tributary device. 

DECnet-VAX software uses a form of circuit identification called a tributary 
address to poll a tributary for a specified circuit. Use the SET CIRCUIT 
command to establish the tributary address. For example, the command 
below specifies an address of 5 to tributary 1 on DMP controller 0. 

NCP>SET CIRCUIT DMP-0.1 TRIBUTARY 5 

Values in the range of 1 to 255 are valid for this parameter. The node at the 
controlling end of this multipoint circuit will use this address to poll this line. 
Correspondingly, you must set the tributary address on the remote node end 
of the circuit that will respond to a polling address of 5. For example: 

NCP>SET CIRCUIT DMP-1.0 TRIBUTARY 5 

The logical tributary number (0 in this case) is not to be confused with the 
tributary address. Refer to the description of logical tributary numbers in the 
circuit identification at the beginning of this section. 


3.5.1.2 Cl Circuit Identification 

The TRIBUTARY parameter is also used to identify the Cl node on the other 
end of a Cl circuit. In the following example, the tributary address 1 identifies 
the Cl node on the other end of circuit CI- <> 1: 

NCP>SET CIRCUIT Cl-0.1 TRIBUTARY 1 

The tributary node address is the Cl port number of the remote Cl node, not 
the DECnet node address. 

Note that you must load the CNDRIVER before running DECnet over a Cl 
(see Section 2.2.3). 
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3.5.1.3 Ethernet Circuit Identification 

For VAX/VMS, Ethernet circuit identification takes the following format: 

dev-c 

dev Is a device name. (The device name for an Ethernet circuit is UNA for a 
VAX/VMS system and QNA for a MicroVMS system.) 

c Is a decimal number (0 or a positive integer) that designates the hardware 
controller for the device. 

For example, the command below identifies the circuit device UNA and the 
controller number 2 for an Ethernet circuit: 

NCP>SET CIRCUIT UNA-2 STATE ON 


3.5.1.4 X.25 Circuit Identification 

Use the SET CIRCUIT command to identify X.25 circuits. The text following 
the X25- prefix in the command string identifies all PVCs and DLM SVCs. 
The text is an alphanumeric string not more than 12 characters in length. 

The entire string, including the prefix X25-, should not be longer than 16 
characters. An example of this command is shown below. 

NCP>SET CIRCUIT X25-ANDIES ... 

Specify unique circuit identifiers for each additional X.25 circuit. For example: 

NCP>SET CIRCUIT X25-PVC0NE ... 

NCP>SET CIRCUIT X25-PVCTW0 ... 


Note that if there is more than one network available, you must specify the 
network to which the circuit belongs. 


3.5.2 Circuit Parameters 

The configuration database contains circuit parameters for all circuits 
connected to the local node or DTE. Table 3-2 lists the types of circuits 
and the circuit parameters that apply to each type. The circuit parameters 
supply information used to control various aspects of a circuit's operation. 
Table 3-3 lists the circuit parameters by function. 


Table 3-2 Types of Circuits and Applicable Circuit Parameters 


Type of Circuit 

All circuits 


Applicable Circuit Parameter 


COUNTER TIMER seconds 

STATE ( 0N ) 

l SERVICE / 


Circuits other than COST cost 

X.25 native PVCs HELLO TIMER seconds 
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Table 3-2 (Cont.) Types of Circuits and Applicable Circuit 
Parameters 


Type of Circuit 

Applicable Circuit Parameter 

DDCMP circuits 

ACTIVE BASE base 

ACTIVE INCREMENT increment 

BABBLE TIMER milliseconds 

DEAD THRESHOLD count 

DYING BASE base 

DYING INCREMENT increment 

DYING THRESHOLD count 

INACTIVE BASE base 

INACTIVE INCREMENT increment 

INACTIVE THRESHOLD count 

MAXIMUM BUFFERS count 

MAXIMUM TRANSMITS count 

POLLING STATE polling-state 

SERVICE ( ENABLED } 
l DISABLED / 

TRANSMIT TIMER milliseconds 

TRIBUTARY tributary-address 

DDCMP circuits and X.25 

DLM circuits (PVCs or SVCs) 

f ENABLED 1 

VERIFICATION } DISABLED \ 

[ INBOUND J 

Ethernet circuits 

MAXIMUM ROUTERS number 

ROUTER PRIORITY number 

X.25 native PVCs 

CHANNEL number 

DTE dte-address 

MAXIMUM DATA count 

MAXIMUM WINDOW count 

NETWORK network-name 

TYPE X25 

USAGE PERMANENT 

X.25 DLM circuits 

BLOCKING ( ENABLED \ 
l DISABLED / 

CHANNEL number 

DTE dte-address 

NETWORK network-name 

MAXIMUM DATA count 

MAXIMUM RECALLS count 

MAXIMUM WINDOW count 

NUMBER dte-address 

OWNER EXECUTOR 

RECALL TIMER seconds 

TYPE X25 

f INCOMING ) 

USAGE 1 OUTGOING > 

l PERMANENT J 
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Table 3-3 Circuit Parameters and Their Function 


Parameter Function 

Indicates owner of circuit 

Identifies circuit by address 

Assigns circuit cost for routing purposes 

Sets counter timer for circuit counter event 
logging 

Sets circuit's operational state 


Parameter 

OWNER EXECUTOR 
TRIBUTARY tributary-address 
COST number 
COUNTER TIMER seconds 



Controls DDCMP multipoint operation 


Sets timer to control Routing layer 

Determines whether service operations 
are allowed for circuit (initiated locally or 
remotely) 

Controls Routing layer initialization of 
adjacent node 


ACTIVE BASE base 
DYING BASE base 
INACTIVE BASE base 
ACTIVE INCREMENT increment 
DYING INCREMENT increment 
INACTIVE INCREMENT increment 
DEAD THRESHOLD count 
DYING THRESHOLD count 
INACTIVE THRESHOLD count 
BABBLE TIMER milliseconds 
TRANSMIT TIMER milliseconds 
MAXIMUM BUFFERS count 
MAXIMUM TRANSMITS count 
POLLING STATE polling-state 
TRIBUTARY 

HELLO TIMER seconds 

SERVICE ( ENABLED 1 
l DISABLED J 

f DISABLED 1 
VERIFICATION } ENABLED \ 
l INBOUND J 


Limits number of routers permitted on MAXIMUM ROUTERS number 

Ethernet circuit 


Sets priority of router on Ethernet circuit for ROUTER PRIORITY number 
selection of designated router 

Associates logical channel number with X.25 CHANNEL number 
PVC 


Specifies the network to which the local DTE NETWORK network-name 
belongs 

Associates local DTE with X.25 PVC DTE dte-address 


Assigns remote DTE address used to NUMBER dte-address 

establishran outgoing DLM SVC to reserve 
an incoming DLM SVC 

Defines circuit type; if circuit is not X.25, TYPE X25 
DDCMP is assumed 


Controls data packet parameters for X.25 MAXIMUM DATA count 
circuits MAXIMUM WINDOW count 
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Table 3-3 (Cont.) Circuit Parameters and Their Function 


Parameter Function 

Parameter 

Determines whether message blocking over 
DLM circuits occurs 

BLOCKING ( CABLED 1 
l ENABLED / 

Controls retransmission of DLM outgoing 
SVCs 

MAXIMUM RECALLS count 
RECALL TIMER seconds 

Use the SET CIRCUIT command to set and modify these parameters. Use 


the CLEAR CIRCUIT command to reset them to their default values (if any) 
or remove them from the volatile database. The circuit must be off before 
you specify the ALL parameter in the CLEAR CIRCUIT command. The 
circuit must also be off if you wish to modify any parameters except COST, 
COUNTER TIMER, SERVICE, STATE, and VERIFICATION. 

Note that not all circuit devices support all parameters listed in the above 
tables. If a particular device does not support a parameter, an error message 
may be displayed. Refer to the VAX/VMS I/O User's Reference Manual: Part 
II for information on specific circuit devices. 


3.5.2.1 Operational State of the Circuit 

Just as you can control the operational state of the local node, you can also 
control the operational state of circuits connected to it. There are three circuit 
states: 

OFF Allows no traffic over a circuit. The circuit is unavailable for 

network activity. 

ON Allows traffic over the circuit. This is the normal operational 

state allowing for complete route-through and downline loading 
operations. 

SERVICE Restricts the circuit to service operations only. Only an Ethernet 
circuit will allow logical link activity or route through at the same 
time as service operations. Service operations include downline 
system loading, upline dumping, and loopback testing. 

Use the STATE parameter to specify the operational state of a circuit. For 
example, this command allows normal traffic over circuit DMC-0: 

NCP>SET CIRCUIT DMC-0 STATE ON 

DECnet-VAX may automatically change the state of a DDCMP circuit for 
certain functions. For example, assume that you have set a DDCMP circuit 
to ON. Later, someone performs a circuit-level loopback test on that circuit 
without first setting the circuit state to SERVICE. Network management 
software automatically turns the circuit to the appropriate internal state (or 
substate) for the test. If the circuit state were displayed at that point, it would 
register as ON-LOOPING. When the circuit is in this state, it is in use for 
an active circuit loop test. This test is termed active because it was initiated 
on the local node. The local node enters the passive loopback state (ON- 
REFLECTING) whenever a remote node initiates a loopback test with the 
local node. When the test finishes, the circuit will return to the ON state. For 
a complete list of circuit states, substates, and their transitions, refer to the 
VAX/VMS Network Control Program Reference Manual. 
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Several circuit substates have the prefix AUTO. These substates can occur 
when an adjacent node is or is about to be in an automatic downline loading 
or triggering stage. For example, if circuit DMC-2 is in the ON state and the 
local node (BOSTON) receives a request for a downline load on that circuit, 
the network software on the local node automatically sets the circuit to the 
ON-AUTOSERVICE state. 

Before performing service operations over a DDCMP circuit, you must enable 
that circuit. To do so, set the SERVICE parameter, which enables or disables 
service operations over a circuit. For example, the command below permits 
the circuit DMC-0 to be put in the SERVICE state, allowing service functions. 

NCP>SET CIRCUIT DMC-0 SERVICE ENABLED 

To disable a DDCMP circuit, set the SERVICE parameter to DISABLED, 
which allows you to restrict the operation of a circuit for network users. The 
default for the SERVICE parameter is DISABLED. 


3.5.2.2 Circuit Timers 

Two timers exist for controlling message transmissions and checking the 
status of adjacent nodes. The first is a hello timer, which defines the 
frequency of Routing layer Hello ("I'm still here") messages sent to the 
adjacent node on the circuit. The second is a listen timer, which controls the 
maximum amount of time allowed to elapse before the Routing layer stops 
waiting for either a Hello message or a user message from the adjacent node 
on the circuit. You cannot set the listen timer with an NCP command; the 
value of the listen timer is always twice the value of the hello timer at the 
local node. 

To set the hello timer, use the command 

NCP>SET CIRCUIT DMP-0 HELLO TIMER 15 

This command sets a limit of 15 seconds between Hello messages from the 
executor node to the adjacent node on circuit DMP-0. The listen interval will 
be 30 seconds between messages from the node on circuit DMP-0 adjacent 
to the executor node. For the HELLO TIMER parameter, you must specify a 
value between 1 and 8191 seconds. The default value for the HELLO TIMER 
parameter is 15 seconds. 

The value of the HELLO TIMER parameter should be the same on all adjacent 
nodes over the same circuit. 

It is recommended that you accept the default value for the HELLO TIMER 
parameter, particularly if your node will communicate with nodes having 
versions of Network Management software earlier than Version 3.0. 


3.5.3 DDCMP Circuit Parameters 

DDCMP circuit parameters include parameters related to verification and to 
control of tributaries. 
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3.5.3.1 DDCMP Circuit Level Verification 

The VERIFICATION parameter applies to DDCMP circuits and to X.25 DLM 
circuits (PVCs and SVCs). 

The VERIFICATION parameter controls whether or not the local node will 
check the Routing layer passwords (RECEIVE PASSWORD and TRANSMIT 
PASSWORD) in the database entry for the remote node before it completes a 
node initialization request from that node. 

To turn on verification, issue the command 

NCP>SET CIRCUIT DMP-0 VERIFICATION ENABLED 

This command specifies that the Routing layer will perform initialization of 
the remote node connected to circuit DMP-0. To turn verification off, use the 
command 

NCP>SET CIRCUIT DMP-0 VERIFICATION DISABLED 

DISABLED is the default, which means that you need not specify a node in 
the configuration database to complete Routing layer initialization. To include 
a remote node in the configuration database, you must specify the NODE 
NAME and ADDRESS parameters; you can optionally specify the RECEIVE 
PASSWORD and TRANSMIT PASSWORD parameters. 

The following rules apply when a remote node submits a node initialization 
request to the local node: 

• Nodes not defined in the remote node database at the local node will not 
be able to initialize over a circuit that has verification enabled. 

• Nodes defined in the remote node database for which receive and transmit 
passwords are not specified will be allowed to initialize whether or not 
verification is enabled on the circuit. 

• Nodes defined in the remote node database for which receive and transmit 
passwords are specified will be allowed to initialize over a circuit with 
verification enabled, provided the receive password in the local database 
matches the transmit password sent by the remote node. 

• Any node will be allowed to initialize over a circuit for which verification 
is disabled. 

The VERIFICATION INBOUND parameter applies to any DDCMP point-to- 
point circuit. When VERIFICATION INBOUND is specified, the remote node 
submitting an initialization request to the local node must supply a transmit 
password that matches the receive password for that node in the local node 
database. The local node, however, will not send its initialization password 
to the requesting node. The VERIFICATION INBOUND parameter provides 
added security for the local node, which can verify the password of a node 
requesting a connection without revealing its own password. 

For example, to require that a remote node supply a password before it can 
initialize on circuit DMP-0 when the local node does not supply a password, 
specify the command 

NCP>SET CIRCUIT DMF-0 VERIFICATION INBOUND 

The VERIFICATION INBOUND parameter is supplied automatically for 
a dynamic asynchronous DDCMP circuit. When a dialup node requests a 
dynamic connection to the local node and the VERIFICATION INBOUND 
parameter is set for the circuit, you must specify the INBOUND parameter for 
the dialup node in the node database. If VERIFICATION INBOUND is not 
specified, the INBOUND parameter in the dialup node entry is ignored. 
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3.5.3.2 DDCMP Tributary Control 

Several circuit parameters enable you to regulate and control tributaries. 
Some of these parameters apply to polling, others to timers. Note that you 
specify these circuit parameters on the control station, not on the tributary 
itself. 

Polling Over DDCMP Circuits 

To control the polling state of a tributary, use the DYING THRESHOLD, 
DEAD THRESHOLD, or INACTIVE THRESHOLD parameters. There are four 
polling states: ACTIVE, INACTIVE, DYING, and DEAD. These parameters 
determine the number of times the control station will poll the active, 
inactive, or dying tributary before changing its polling state. For example, 
the command below sets the polling threshold for circuit DMP-0.3. 

NCP>SET CIRCUIT DMP-0.3 DYING THRESHOLD 5 

The control station will attempt to poll its tributary 5 times. If it gets receive 
timeouts for five consecutive polls, the control station changes the tributary's 
polling state from ACTIVE or INACTIVE to DYING. Values for the DYING 
THRESHOLD parameter range from 0 to 255 and the default is 2. The 
following command sets the polling threshold for circuit DMP-0.1: 

NCP>SET CIRCUIT DMP-0.1 INACTIVE THRESHOLD 12 

The control station will attempt to poll its active tributary 12 times. If it 
receives only acknowledgments, but no data responses, the control station 
changes the active tributary's polling state to INACTIVE. The values for the 
INACTIVE THRESHOLD parameter range from 0 to 255 and the default is 8. 

You can lock a tributary into one of the four states by using the POLLING 
STATE parameter. Usually, the tributary's state is allowed to vary according 
to the multipoint polling algorithm. This variance occurs when this parameter 
is set to AUTOMATIC. Use this parameter to lock a tributary into the 
ACTIVE, INACTIVE, DYING, or DEAD state. For example, this command 
locks the tributary controlled by circuit DMP-0.1 into a DEAD state: 

NCP>SET CIRCUIT DMP-0.1 POLLING STATE DEAD 

The base priority of a tributary is the lowest value to which that tributary can 
be set after a poll. A control station polls tributaries with high priorities first. 
Note that a control station will not poll tributaries with priorities below 128. 
To specify the base priority for a tributary, use the ACTIVE BASE, INACTIVE 
BASE, or DYING BASE parameters. After polling the tributary, the control 
station resets the base priority of the active, inactive, or dying tributary to 
this value. You can set a separate base value for each of the polling states, as 
shown in the following example: 

NCP>SET CIRCUIT DMP-1.2 ACTIVE BASE 225 

After a poll, the command above resets the base priority of the tributary on 
circuit DMP-1.2 to 225. The values for all BASE parameters range from 0 to 
255. The defaults are ACTIVE, 255; INACTIVE, 0; and DYING, 0. 

You can also increment the priority of a tributary each time the line¬ 
scheduling timer expires. If, for instance, the polls pass over a tributary 
with a low priority, you can raise the priority of that tributary by using the 
ACTIVE INCREMENT, INACTIVE INCREMENT, or DYING INCREMENT 
parameters. When the scheduling timer expires on an unpolled tributary, it 
increases the priority according to the value you set. You can set a separate 
increment value for each polling state, as shown in the following example: 

NCP>SET CIRCUIT DMP-2.2 INACTIVE INCREMENT 200 
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This command adds 200 to the base priority of the tributary on circuit DMP- 
2.2. The increment values range from 0 to 255. The defaults are ACTIVE, 

0; INACTIVE, 64; and DYING, 16. Note that if you set a 0 increment on 
a tributary with a base priority lower than 128, the tributary will never be 
polled. Active tributaries usually have a high base priority and, therefore, do 
not need a high increment value. 

The MAXIMUM BUFFERS and MAXIMUM TRANSMITS parameters give 
you further control over the tributary. MAXIMUM BUFFERS specifies the 
maximum number of buffers that a tributary can use from the common buffer 
pool. If you do not set this parameter explicitly, the default is 4. Values 
for this parameter can be either integers ranging from 1 to 254 or the word 
UNLIMITED. For example, this command sets an upper limit of 10 buffers 
that the tributary on this circuit can use from the common buffer pool: 

NCP>SET CIRCUIT DMP-0.2 MAXIMUM BUFFERS 10 

The MAXIMUM TRANSMITS parameter specifies the maximum number of 
data messages that the tributary can transmit in a single poll interval. Values 
range from 1 to 255; the default is 4. For example, the command below 
sets an upper limit of two data message transmits from the tributary on this 
circuit. 

NCP>SET CIRCUIT DMP-0.2 MAXIMUM TRANSMITS 2 

DDCMP Tributary Circuit Timers 

Two timers exist for controlling message retransmission at the DDCMP 
tributary circuit level. The babble timer controls the amount of time that a 
tributary or remote half-duplex station can transmit; the transmit timer sets 
the amount of time to delay between data message transmissions. To specify 
these timers, use these commands: 

NCP>SET CIRCUIT DMP-0.1 BABBLE TIMER 8000 
NCP>SET CIRCUIT DMP-0.1 TRANSMIT TIMER 4000 

The first command limits transmission time to 8 seconds (8000 milliseconds) 
for the circuit's tributary. Values for the BABBLE TIMER parameter range 
from 1 to 65,535; the default is 6000 (6 seconds). 

The second command sets a delay of 4 seconds (4000 milliseconds) between 
each transmission from the tributary. Values for the TRANSMIT TIMER 
parameter range from 0 to 65,535; the default is 0. 


3.5.4 Ethernet Circuit Parameters 

Parameters that Ethernet circuits have in common with other DECnet- 
VAX circuits are HELLO TIMER, COST, COUNTER TIMER and STATE. 
Parameters unique to Ethernet circuits are ROUTER PRIORITY and 
MAXIMUM ROUTERS, which you can specify in the SET CIRCUIT 
command. 

If there are two or more routers on the same Ethernet, the one with the 
highest numerical priority (up to a maximum value of 127) is elected the 
designated router. The designated router provides message routing services 
for end nodes on the Ethernet (see Section 2.4.4.1). A designated router 
is selected even if there are currently no end nodes on the Ethernet. Note 
that routers are not required in order to route messages over the Ethernet 
on behalf of end nodes; Ethernet end nodes are capable of communicating 
directly. However, routers are required to route messages off of the Ethernet 
over other circuits such as DDCMP circuits. 
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Use the SET CIRCUIT command to set the ROUTER PRIORITY value in the 
applicable circuit database at the executor node. For example, the following 
command assigns a router priority of 70 to local node ROBIN on circuit 
UNA-0: 

NCP>SET CIRCUIT UNA-0 ROUTER PRIORITY 70 

Each node on Ethernet circuit UNA-0 is assigned a router priority value in 
the range 0 through 127; the default value is 64. DECnet software compares 
the router priority values of the nodes and elects the router with the highest 
priority the designated router. If two or more nodes on the Ethernet have the 
same highest router priority value, the node with the highest node address is 
selected as designated router. To learn which router is the designated router, 
issue a SHOW ACTIVE CIRCUITS CHARACTERISTICS command. The 
following information will be displayed for circuit UNA-0: 

Designated router = 1.224 (ROBIN) 

Router priority = 70 

The recommended limit on the number of routers on an Ethernet circuit is 
10, because of the control traffic overhead (composed of routing messages 
and hello messages) involved. The maximum number of routers allowed is 
33. The MAXIMUM ROUTERS parameter specifies the maximum number 
of routers (other than the executor node) that the Routing layer is to allow 
on a particular Ethernet circuit. Use the SET CIRCUIT command to assign 
the MAXIMUM ROUTERS value for an Ethernet circuit. For example, the 
following command sets a maximum value of 4 to the number of routers (in 
addition to the executor node) that are permitted on circuit UNA-0: 

NCP>SET CIRCUIT UNA-0 MAXIMUM ROUTERS 4 

The default value is 33. 


3.5.5 Ethernet Configurator Module Commands 

Use the Ethernet configurator module to obtain a list of all systems on an 
Ethernet circuit or circuits. Each DIGITAL-supported node on an Ethernet 
circuit periodically transmits a system identification message to a multicast 
address to which the Ethernet configurator listens. The configurator uses 
these messages to build the configuration list. 

Use NCP commands to access and control the configurator module. The 
configurator runs as a separate process, available to all users on the system. 
Once the configurator is started, it will continue to execute, maintaining and 
updating its database of information on active nodes until a user causes it to 
stop listening to system identification messages. 

If several users of a particular system issue SET MODULE CONFIGURATOR 
commands, they will all access the same configurator module. To determine 
whether the configurator module is already running, issue the following 
command: 

NCP>SH0W MODULE CONFIGURATOR KNOWN CIRCUITS 
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3.5.5.1 


3.5.5.2 


Enabling Surveillance by the Ethernet Configurator 

To create or modify Ethernet configurator module parameters in the 
volatile database, use the SET MODULE CONFIGURATOR command. 

The SURVEILLANCE ENABLED parameter in this command causes the 
configurator module to begin listening to system identification messages 
transmitted by all systems on the circuit or circuits specified in the command. 
The configurator collects this information and constructs a list of systems and 
their capabilities in the volatile database. 


Obtaining a List of Systems on Ethernet Circuits 

To obtain information on the current configuration of nodes on Ethernet 
circuits, use the SHOW MODULE CONFIGURATOR command. This 
command permits you to access the configurator volatile database, which 
contains the following information for each system: 

• The Ethernet physical and hardware addresses of the system 

• The device connecting the system to the Ethernet 

• The maintenance version number of the system 

• A list of maintenance functions that can be performed by the node 

• The last time a system identification message was received from that 
system 


The SHOW MODULE CONFIGURATOR command causes the configurator to 
display this information along with the amount of time surveillance has been 
enabled on the circuit. For example, for circuit UNA-0, the command 

NCP>SH0W MODULE CONFIGURATOR CIRCUIT UNA-0 STATUS 


will result in the following display: 


Module Configurator Volatile Status as of 22-MAR-1986 09:15:25 


Circuit name 
Surveillance flag 
Elapsed time 
Physical address 
Time of last report 
Maintenance version 
Function list 
Hardware address 

Device type 

Circuit name 
Surveillance flag 
Elapsed time 
Physical address 
Time of last report 
Maintenance version 
Function list 
Hardware address 
Device type 


= UNA-0 
= enabled 
= 00:32:43 
= AA-00-04-00-A3-04 
= 22-Mar 9:14:8 
= V3.0.0 

= Loop, Primary loader 
= AA-00-03-00-00-07 
= UNA 

= UNA-0 
= enabled 
= 0:32:43 

= AA-00-04-00-A1-04 
= 22-Mar 9:11:29 
= V3.0.0 

= Loop, Primary loader 
= AA-00-03-00-00-57 
= UNA 
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3.5.5.3 Disabling Surveillance by the Ethernet Configurator 

To cause the configurator to stop listening to system identification messages 
on specific Ethernet circuits, use the SURVEILLANCE DISABLED parameter 
of the SET MODULE CONFIGURATOR command. If you specify the 
KNOWN CIRCUITS parameter in this command, the configurator no longer 
listens to system identification messages being broadcast on any Ethernet 
circuit known to the local node. For example, this command causes the 
configurator to cease surveillance of all Ethernet circuits known to local node 
ROBIN: 

NCP>SET MODULE CONFIGURATOR KNOWN CIRCUITS - 
_ SURVEILLANCE DISABLED 

Once the configurator ceases surveillance of all Ethernet circuits it has been 
monitoring, the list of system information is deleted. 


3.5.6 X.25 Circuit Parameters 

The circuit parameters described below apply to permanent virtual circuits 
(PVCs) used for X.25 operations. 


3.5.6.1 Parameters Common to X.25 Circuits 

The TYPE X25 and USAGE parameters are common to all X.25 circuits. 

Use the TYPE parameter to specify an X.25 circuit as follows: 

NCP>SET CIRCUIT X25-ANDIES ... TYPE X25 ... 

Note that, by default, when the name of the circuit starts with "X25," for 
example, X25-ANDIES, the circuit type is X.25. The TYPE parameter is 
optional. 

Use the USAGE parameter to specify that the circuit is a PVC as follows: 

NCP>SET CIRCUIT X25-ANDIES ... USAGE PERMANENT ... 

USAGE PERMANENT indicates that the circuit is permanently connected to 
a remote DTE and does not need to be switched dynamically. The USAGE 
parameter is mandatory for PVCs and takes no default. 


3.5.6.2 Permanent Virtual Circuit Parameters 

When PVCs are first specified, the CHANNEL and DTE parameters are 
mandatory. In addition, the NETWORK parameter is mandatory if more than 
one network is set up. 

The CHANNEL parameter is used to associate a logical channel number with 
each PVC. This number is allocated to you by the PSDN at subscription time 
and will be in the range 1 to 4095. Each PVC different from those previously 
specified for outgoing calls in the SET MODULE X25-PROTOCOL command 
must have a unique channel number. The command below illustrates the use 
of this CHANNEL parameter. 

NCP>SET CIRCUIT X25-ANDIES ... CHANNEL 3 ... 

The DTE parameter is used to associate the local DTE address with each PVC. 
The command below illustrates the use of the DTE parameter. 

NCP>SET CIRCUIT X25-ANDIES ... DTE 123789456 ... 

The DTE address is a decimal integer of 1 to 15 digits and must have been 
specified previously in a SET MODULE X25-PROTOCOL command. 
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The NETWORK parameter defines the network to which the DTE connects. 
For example, 

NCP>SET CIRCUIT X25-ANDIES ...NETWORK TELENET1 

The network must have been defined previously with a SET MODULE 
X25-PROTOCOL command. 


3.5.6.3 Data Packet Control 

Two parameters control the transmission of data packets over the PVC: 
MAXIMUM DATA and MAXIMUM WINDOW. 

The MAXIMUM DATA parameter specifies the maximum size of the packet 
for a particular circuit. For example, the following command sets the 
maximum size of the packet to 128 bytes for the circuit ANDIES: 

NCP>SET CIRCUIT X25-ANDIES ... MAXIMUM DATA 128 ... 

The maximum packet size must always be at least 5 bytes smaller than the 
maximum size of the frame on a line (see Section 3.6.5.1). Specify a value 
that is a power of 2 in the range 16 to 4096 bytes. 

The MAXIMUM DATA parameter is optional and, by default, takes the 
network value. See the VAX PSI Public Network Information Cards for the 
network value of this parameter. 

The MAXIMUM WINDOW parameter specifies the window size for a 
particular PVC. For example, the command that follows sets the window 
size to 2 for the circuit X25-ANDIES: 

NCP>SET CIRCUIT X25-ANDIES ... MAXIMUM WINDOW 2 ... 

Specify a value in the range 1 to 127. 

The MAXIMUM WINDOW parameter is optional and, by default, takes the 
network value. See the VAX PSI Public Network Information Cards for the 
network value of this parameter. 

Both parameters, if specified, must be set to values that agree with your 
PSDN subscription. 


3.5.7 DLM Circuit Parameters 

A data link mapping (DLM) circuit allows an X.25 virtual circuit to be used as 
a DECnet data link in communicating with other DECnet nodes over a PSDN. 
Several circuit parameters are specific to the operation of DLM circuits: the 
OWNER EXECUTOR parameter, the remote DTE address and the network 
name used by DECnet to establish a DLM outgoing switched virtual circuit, 
the USAGE parameter for a DLM circuit, and two parameters to regulate 
recalls for DLM outgoing SVCs. 

Parameters that DLM circuits have in common with other X.25 circuits are 
CHANNEL, DTE, MAXIMUM DATA, and MAXIMUM WINDOW. The circuit 
parameter VERIFICATION applies to DLM circuits and DDCMP circuits. 
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3.5.7.1 DLM Circuit Owner 

The OWNER EXECUTOR parameter is used to indicate that the Routing 
layer has exclusive rights to use the circuit. To specify that the circuit X25- 
DLMOUT should be used as a DLM circuit, use the following command: 


NCP>SET CIRCUIT X25-DLM0UT OWNER EXECUTOR 

The OWNER EXECUTOR parameter is required for a DLM circuit. 


3.5.7.2 Remote DTE Addresses 

To establish an SVC with a remote DTE, DECnet software requires the 
address of the remote DTE. Use the NUMBER parameter in the SET CIRCUIT 
command to specify the remote DTE address for incoming or outgoing DLM 
SVCs. 

For outgoing calls, the Routing layer uses this address (and the subaddresses 
required at the remote DTE) to call on the circuit. For example: 

NCP>SET CIRCUIT X25-DLM0UT NUMBER 31191234567842 

Outgoing calls on circuit X25-DLMOUT use the DTE 311912345678 and a 
subaddress of 42 to establish an SVC with a remote DTE associated with this 
address. 

For incoming calls, the NUMBER parameter is used to force them to a 
particular circuit on the basis of the remote DTE address. If a NUMBER 
parameter is specified for each incoming DLM circuit at the local DTE, an 
incoming call from a remote DTE will be rejected if its address does not 
match the number specified for any incoming circuit. If any incoming circuit 
does not have a number specified, then the circuit can handle calls from any 
DTE. The NUMBER parameter can also be used with an incoming circuit to 
specify additional routing parameters for a selected DTE. For example: 

NCP>SET CIRCUIT X25-INC USAGE INCOMING - 
_ NUMBER 31191234567842 COST 15 

Circuit X25-INC will receive calls only from the remote DTE with the DTE 
311912345678 and subaddress 42. In this example, a cost of 15 is assigned to 
the DLM connection to remote DTE 311912345678 to reflect a higher routing 
cost for this configuration. 

Note: If there is more than one network available, you must specify to which 
network the circuit belongs. 


3.5.7.3 Recalls for DLM Circuits 

If previous attempts to establish a DLM SVC have been unsuccessful, 
DECnet-VAX attempts to recall a number. The frequency of recalls and the 
maximum number of recalls DECnet attempts can be set with two parameters. 
The RECALL TIMER parameter sets the interval that DECnet should wait 
before attempting to place a call to establish an SVC. The MAXIMUM 
RECALLS parameter specifies the maximum number of times DECnet should 
attempt to place a call to establish an SVC. The command below will cause 
DECnet-VAX to place a call every 10 seconds for a maximum of 10 times to 
establish an SVC for circuit X25-DLMOUT. 

NCP>SET CIRCUIT X25-DLM0UT RECALL TIMER 10 - 
_ MAXIMUM RECALLS 10 
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The default value for the RECALL TIMER parameter is 3 seconds. Unless 
you specify a value for the MAXIMUM RECALLS parameter, DECnet-VAX 
places no limit on the number of recalls attempted. If an attempt to make 
an outgoing call causes the system to exceed the MAXIMUM RECALLS 
parameter, the circuit is placed in the OFF state, and the following command 
is required before the outgoing call can be attempted again: 

NCP>SET CIRCUIT X25-DLM0UT STATE ON 


3.5.7.4 DLM Circuit Usage 

DLM circuits operate according to the usage you define for them in the 
volatile database. DLM SVCs may be used either for outgoing or incoming 
calls. The usage of DLM PVCs is PERMANENT; that is, the circuit is 
permanently connected to a remote DTE, and does not need to be switched 
dynamically. The USAGE parameter specifies how DLM circuits are to be 
used, as in the following example: 

NCP>SET CIRCUIT X25-DLM0UT USAGE OUTGOING ... 


3.5.7.5 Executor Node Subaddresses 

When you are configuring the network, you can define a range of 
subaddresses that the DECnet Routing layer will accept as incoming DLM 
calls. VAX PSI will route all incoming calls within the specified subaddress 
range to the Routing layer, to be handled as DLM circuits. You are 
responsible for ensuring that the subaddress specified in the outgoing DLM 
NUMBER parameter (see Section 3.5.7.2) matches the range of subaddresses 
on the incoming side, as specified in the EXECUTOR SUBADDRESSES 
parameter of the SET EXECUTOR command. 

When the Routing layer receives an incoming call from a DTE, it scans the 
incoming DLM circuits to find the address of the DTE sending the call that 
matches the remote DTE address specified for the circuit (in the NUMBER 
parameter of the SET CIRCUIT command). If an incoming circuit does not 
have the NUMBER parameter specified, that circuit is selected to accept 
any incoming call that has not yet been matched to a particular circuit. If all 
incoming circuits have the NUMBER parameter specified and a call is received 
from a DTE whose address does not match any circuit, that call is rejected. 

Use the SUBADDRESSES parameter in the SET EXECUTOR command to 
specify executor subaddresses (Section 3.3 describes the SET EXECUTOR 
command). For example, use the SET EXECUTOR command to modify 
subaddresses in the volatile database: 

NCP>SET EXECUTOR SUBADDRESSES 42 

The command above indicates that the Routing layer handles only incoming 
X.25 calls that specify local DTE subaddress 42. All other calls are handled by 
VAX PSI. A subaddress may consist of a range. For example, the command 
below indicates that the Routing layer all incoming X.25 calls that specify a 
local DTE subaddress in the range of 42 to 50: 

NCP>SET EXECUTOR SUBADDRESSES 42-50 

When specifying a subaddress range, use an integer in the range of 0 to 9999. 
Separate two subaddresses with a hyphen to indicate a range, and be sure the 
second subaddress is always greater than the first. 
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3.5.7.6 Setting Up a DLM Circuit 

The following example illustrates how to set up a DLM circuit between 
DECnet node A (DTE address 123) and DECnet node B (DTE address 456), 
which are to communicate over a PSDN. 

On node A, the following command is used to specify the outgoing DLM 
circuit in the volatile database: 

NCP>SET CIRCUIT X25-0UTG0ING - 
TYPE X25 - 
OWNER EXECUTOR - 
_ USAGE OUTGOING - 
NUMBER 4561 - 
STATE ON 

The command must specify the DTE address and subaddress of the remote 
node. The value in the NUMBER parameter represents DTE 456 subaddress 
1 . 

On node B, the following command indicates that the DECnet Routing layer 
will accept all incoming calls to this node (DTE) that have a subaddress in the 
range 1 to 20: 

NCP>SET EXECUTOR SUBADDRESSES 1-20 

Note that this command must be issued at node B before node B can accept 
calls from node A. 

The following command at node B is then used to specify the incoming DLM 
circuit in the volatile database: 

NCP>SET CIRCUIT X25-INC0MING - 
TYPE X25 - 
OWNER EXECUTOR - 
_ USAGE INCOMING - 
STATE ON 


3.5.8 Circuit Counters 


DECnet-VAX automatically maintains certain statistics for circuits in the 
network. These statistics are known as circuit counters. For all circuits, 
counter information may include the number of data packets sent, received, 
and lost over the circuit; timeouts; and the amount of time since the counters 
were last zeroed. For DDCMP circuits, counters are maintained for timeouts 
and data and buffer errors, and for both DDCMP and Ethernet circuits, the 
number of bytes and data blocks sent and received. For X.25 circuits, the 
following statistics are indicated in counters: the time since the counters 
were zeroed; the number of bytes, data blocks and resets sent and received; 
and the number of resets initiated by the network. Information obtained 
from counters may be useful either alone or in conjunction with logging 
information to measure the performance and throughput for a given circuit. 
See the VAX/VMS Network Control Program Reference Manual for a complete 
list of circuit counters. Refer to Section 2.9 for a discussion of logging. 

You can use NCP to regulate the frequency with which circuit counters are 
logged and when they are zeroed. At any point while the network is running, 
you can also display circuit counter statistics using the SHOW CIRCUIT 
COUNTERS command. 
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To set a timer whose expiration automatically causes the circuit counters to be 
logged at the logging sink and then zeroed, use the SET CIRCUIT command 
with the COUNTER TIMER parameter. The following command causes a 
circuit counter logging event to take place every 600 seconds: 

NCP>SET CIRCUIT DMC-0 COUNTER TIMER 600 

To clear this parameter, use the NCP command below. 

NCP>CLEAR CIRCUIT DMC-0 COUNTER TIMER 

At any point when the network is running, you can zero counters for a given 
circuit or for all known circuits. Use the following commands to zero circuit 
counters: 

NCP>ZER0 CIRCUIT DMC-0 COUNTERS 
NCP>ZER0 KNOWN CIRCUITS COUNTERS 


3.6 Line Commands 

DECnet-VAX supports four classes of lines: DDCMP, Cl, Ethernet, and X.25. 
You must use NCP commands to identify all physical lines connected to the 
local node and to specify parameters that affect operation of the lines. This 
section describes line identification and discusses the line parameters you can 
use. 


3.6.1 Line Identification 

As with nodes and circuits, lines must have unique identifiers. The line and 
circuit names identify a logical connection. For VAX/VMS, line identification 
takes one of the following formats: 

dev-c 
dev-c[-u] 

dev Device name. (Refer to the VAX/VMS Network Control Program Reference 
Manual for a complete list of mnemonic device names.) 

c Decimal number (0 or a positive integer) designating the device's hardware 
controller. 

u Decimal unit or line number (0 or a positive integer) included if the device is 
a multiple unit line controller. For all non-multiplexed lines, the unit number 
is optional and, if specified, is always zero (0). 

Note: Devices which are similar in operation are referred to by the same 
mnemonic. 

VAX/VMS maps network management line names to system-specific line 
names (for example, DMC-4 maps to XME0). Network management line 
names provide networkwide line identification independent of individual 
operating system conventions. 

The following commands illustrate line identification. The command below 
specifies a synchronous DDCMP point-to-point line, identifying the DMC (or 
DMR) line device and controller number 0: 

NCP>SET LINE DMC-0 STATE ON 
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The command below specifies an asynchronous DDCMP point-to-point line. 
It identifies the DMF32 asynchronous line unit by the mnemonic TX and 
specifies controller number 0 and unit number 0 (that is, TXAO). 

NCP>SET LINE TX-0-0 RECEIVE BUFFERS 4 STATE ON 

When you turn on an asynchronous line, it is advisable to set the number of 
receive buffers to a value of 4 or more (see Section 3.6.3.1). 

Note that dynamic asynchronous DDCMP line names are supplied 
automatically when a dynamic connection is established. 

The following command specifies the Cl line CI-0: 

NCP>SET LINE CI-0 STATE ON 

The command below specifies the Ethernet line UNA-0: 

NCP>SET LINE UNA-0 STATE ON 

The command below specifies the X.25 line DUP-0: 

NCP>SET LINE DUP-0 STATE ON 

For each X.25 line, specify a unique device, for example: 

DMF-0 

DUP-0 

KMX-0-0 

KMX-0-1 

KMV-0 


3 . 6 . 1.1 


Line Protocols 

As part of the process of identifying lines, you must specify the line protocol. 
To ensure that the data link protocol operates properly when information is 
transferred over a line, use the SET LINE command with the PROTOCOL 
parameter to specify a line protocol. The protocols are as follows: 


DDCMP CONTROL 

DDCMP DMC 

DDCMP POINT 

DDCMP TRIBUTARY 

ETHERNET 

LAPB 

LAPBE 


Specifies the line as a multipoint control station. You 
can set multiple circuits for CONTROL lines. Each circuit 
must have a unique physical tributary address. 

Specifies that the line is in DMC emulator mode. DMC is 
similar to DDCMP POINT protocol, except that DMC uses 
an older version of DDCMP (Version 3.2). This protocol 
should be set for the local line when the remote line is a 
DMC. 

Specifies the line as one end of a point-to-point DDCMP 
connection. You may specify only one circuit per POINT 
line. 

Specifies that the line is a multipoint tributary end of a 
DDCMP multipoint group. You may specify only one 
circuit per TRIBUTARY line. 

Specifies that the line is a multiaccess line that uses the 
Ethernet protocol. 

Specifies that the line uses the X.25 level 2 protocol. 
The line must be used by the X25-PROTOCOL module. 

Specifies that the line uses the X.25 level 2 protocol 
with extended sequencing. The line must be used by 
the X25—PROTOCOL module. 
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Note that you do not specify any protocol for a Cl line. The Cl uses its own 
private protocols for communication between nodes. 

If you do not specify a line protocol, the default values below apply, 
according to the device specified. 


Device 

Protocol 

DMC/DMR 

DDCMP POINT 

DMP/DMV 

DDCMP POINT 

DMF 

DDCMP POINT 

TT/TX 

DDCMP POINT 

DUP/DPV 

LAPB 

KMX 

LAPB 

KMV 

LAPB 

KMY 

LAPB 

QNA 

ETHERNET 

UNA 

ETHERNET 

Cl 

None (not specified) 


The SET LINE PROTOCOL examples below specify line protocols in the 
configuration database at the local node and on remote nodes other than 
DECnet-VAX, such as DECnet-RSX. For example, the command below 
identifies line DMP-0 as a multipoint control station: 

NCP>SET LINE DMP-0 PROTOCOL DDCMP CONTROL 

You set this parameter in the database of the local node at the controlling end 
of this line. A tributary for this line could be specified as 

NCP>SET LINE DMP-1 PROTOCOL DDCMP TRIBUTARY 

You set this parameter in the database of the remote node connected to the 
tributary end of the control station for that line. 


3.6.2 Line Parameters 


The configuration database should contain line parameters for all physical 
lines connected to the local node or DTE. These parameters supply 
information used to control various aspects of a line's operation. Table 3-4 
lists the types of lines and the line parameters applicable to them. Table 3-5 
lists all line parameters by function. 

Table 3-4 Types of Lines and Applicable Line Parameters 

Type of Line Applicable Line Parameter 

All lines CONTROLLER controller-mode 

COUNTER TIMER seconds 

STATE { 0N ) 
l OFF / 

All lines except Cl PROTOCOL protocol-name 

All lines except X.25 lines BUFFER SIZE number 
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Table 3-4 (Cont.) Types of Lines and Applicable Line 
Parameters 


Type of Line 

Applicable Line Parameter 

All lines except Ethernet lines 

DDCMP lines 

RETRANSMIT TIMER millisecond 

CLOCK clock-mode 

DEAD TIMER milliseconds 

DELAY TIMER milliseconds 

DUPLEX duplex-mode 

RECEIVE BUFFERS count 

SCHEDULING TIMER milliseconds 

SERVICE TIMER milliseconds 

STREAM TIMER milliseconds 

DMR1 1 lines 

TRANSMIT PIPELINE count 

Asynchronous DDCMP lines 

HANGUP ( DISABLED 1 
l ENABLED / 

LINE SPEED number 

SWITCH option 

X.25 lines 

MAXIMUM BLOCK count 

INTERFACE interface-code 

MAXIMUM RETRANSMITS count 

MAXIMUM WINDOW count 

MICROCODE DUMP file-spec 

NETWORK network-name 

PROTOCOL LAPB or LAPBE 

STATE SERVICE 


Table 3-5 Line Parameters and Their Functions 


Parameter Function 

Parameter 

Defines line protocol 

r DDCMP CONTROL 

DDCMP POINT 

DDCMP DMC 

PROTOCOL DDCMP TRIBUTARY ► 
ETHERNET 

LAPB 
, LAPBE 

Sets counter timer for line counter 
event logging 

Selects clock type 

COUNTER TIMER seconds 

n nrkr / INTERNAL \ 

CLOCK ( EXTERNAL J 

Sets line's operational state 

f OFF ) 

STATE \ ON } 

l SERVICE J 

Sets maximum receive buffer size 
for logical links over specific line 

Sets number of buffers in receive 
queue 

BUFFER SIZE number 

RECEIVE BUFFERS number 
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Table 3-5 (Cont.) Line Parameters and Their Functions 


Parameter Function 

Parameter 

Establishes physical line control 
parameters for DDCMP protocol 

° UPLE>< { HALF } 

DEAD TIMER milliseconds 

DELAY TIMER milliseconds 

RETRANSMIT TIMER milliseconds 
SCHEDULING TIMER milliseconds 

SERVICE TIMER milliseconds 

STREAM TIMER milliseconds 

Specifies asynchronous DDCMP 
line characteristics 

HANGUP ( DISABLED 1 
l ENABLED J 

LINE SPEED number 

SWITCH ( DISABLED j 
l ENABLED / 

Establishes line-level loopback 
control for controller operation 

CONTROLLER ( LOOPBACK j 
l NORMAL / 

Establishes frame control 
parameters for X.25 line 

MAXIMUM BLOCK count 

MAXIMUM WINDOW count 

Controls retransmission of frames 
for X.25 line 

MAXIMUM RETRANSMITS count 
RETRANSMIT TIMER 

Controls packet transmission over 
satellite link 

TRANSMIT PIPELINE count 

Defines the way in which the line 
is used 

INTERFACE ( DTE \ 

X DCE / 


Use the SET LINE command to establish and modify these parameters. 

The line must be set to OFF if you wish to modify any parameters except 
COUNTER TIMER, SERVICE, SERVICE TIMER, and STATE. STATE is a 
required parameter for all lines that you specify in the configuration database. 
Use the CLEAR LINE command to reset parameters to their default values (if 
any) in the volatile database. The line must be off before you specify the ALL 
parameter in the CLEAR LINE command. 

Note that not all circuit devices support all parameters listed in the above 
tables. If a particular device does not support a parameter, an error message 
may be displayed. Refer to the VAX/VMS I/O User's Reference Manual: Part 
II for information on specific circuit devices. 


3.6.2.1 Operational State of Lines 

As with local node and circuit states, you can control the operational state of 
lines connected to the local node or to the local DTE. There are three possible 
line states: 

OFF Allows no traffic over a line. The line is unavailable for network 

activity. 

ON Allows traffic over the line. The ON state is the normal operational 

state, which allows complete route-through and downline loading 
operations. 

SERVICE Allows only restricted line service over the line. This traffic includes 
loopback testing. (Used only for X.25 lines.) 
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Use the STATE parameter to specify the operational state of a line. For 
example, to allow normal traffic over line DMC-0, use the following 
command: 

NCP>SET LINE DMC-0 STATE ON 

The command below specifies the operational state of an X.25 line, allowing 
normal traffic over the DUP-0: 

NCP>SET LINE DUP-0 STATE ON 

The STATE parameter is optional and, by default, is set to OFF. 


3.6.2.2 Buffer Size 

You can increase the maximum size of receive buffers (and therefore the 
size of NSP messages) that can be transmitted over a particular line by 
specifying the BUFFER SIZE parameter in the SET LINE command. For 
certain logical links established over the line to adjacent nodes, this BUFFER 
SIZE value overrides the executor node BUFFER SIZE limit specified in the 
SET EXECUTOR command (see Section 3.3.5.1). 

If you specify the BUFFER SIZE parameter for a line, the adjacent node on 
any new logical link initiated over that line can optionally accept an NSP 
message segment size that is based on the BUFFER SIZE value. If the remote 
node accepts the segment size, the logical link to that node is then tied to 
that circuit. If the circuit fails, the logical link does not automatically route 
the packet through an alternate circuit; that is, the logical link becomes 
nonadaptive. 

For example, the following command sets the maximum size of receive 
buffers for line UNA-0 to 1400 bytes, but only for logical links to adjacent 
nodes that accept 1400 bytes as the NSP segment size. 

NCP>SET LINE UNA-0 BUFFER SIZE 1400 

If the adjacent node does not accept a segment size based on the BUFFER 
SIZE value, the default for any line except an Ethernet line is the executor 
node's BUFFER SIZE value. The default for an Ethernet line is 1498 bytes. 

This feature can be used to maximize performance over high-speed links, 
such as Ethernet, by using a large value for the BUFFER SIZE parameter and 
causing all logical links between adjacent nodes on the Ethernet to use that 
larger message size. 


3.6.3 DDCMP Line Parameters 

Several parameters regulate various aspects of a DDCMP line's physical 
protocol operation. You can specify the number of receive buffers, the duplex 
mode, and the timers for both normal and service operations. 

Parameters that apply specifically to asynchronous DDCMP lines indicate 
the speed of the line, whether modem signals are dropped when a line is 
shut down, and whether an asynchronous line is switched back to a terminal 
line when disconnected from the network. For a dynamic asynchronous line, 
DYNSWITCH supplies these parameters to NETACP automatically. 

DDCMP line parameters are described below. 


3-53 










Managing and Monitoring the Network 


3.6.3.1 Line Buffers 

To allocate buffers for data reception by the device driver for a particular 
DDCMP line, use the RECEIVE BUFFERS parameter. The following 
command sets four buffers for this line: 

NCP>SET LINE DMC-1 RECEIVE BUFFERS 4 

Values for this parameter range from 1 to 32. The number of buffers you 
set will depend on throughput requirements and available memory pool. A 
value in the range of 2 to 4 is adequate for line speeds of less than 56K bits. 
For asynchronous lines, a value of at least 4 is recommended. Megabit line 
speeds may require eight or more buffers, depending on the observed errors. 
For LAPB lines, see the description of X.25 line parameters in Section 3.6.5. 


3.6.3.2 Duplex Mode 

To set the duplex mode for a DDCMP line, use the DUPLEX parameter. 
For example, the following command sets the mode of the DMC11 device 
controller to full duplex for line DMC-1: 

NCP>SET LINE DMC-1 DUPLEX FULL 

Generally, you use full-duplex mode for local lines and permanently wired 
telephone lines; you usually use half-duplex mode for dialup remote 
telephone lines used with half-duplex synchronous modems. If you use a 
modem, consult the manufacturer's documentation for full- or half-duplex 
characteristics. 


3.6.3.3 Line Timers 

Line timers control the frequency of message retransmission at the DDCMP 
level. There are six line timers. 

• Service timer. The service timer sets the maximum amount of time 
allowed to elapse before a retransmission is necessary when service 
operations are under way. 

• Retransmit timer. The retransmission timer sets the maximum amount of 
time allowed to elapse before a retransmission is necessary on a multipoint 
line. This is the amount of time a control station will wait for a tributary 
to respond. For a DMF32 tributary, it is the maximum amount of time the 
tributary will hold the line before returning control to the control station. 
For an X.25 line, it is the maximum amount of time before a frame is 
retransmitted (see Section 3.6.5.1). 

• Dead timer. The dead timer sets the amount of time between polls of the 
dead tributaries. 

• Delay timer. The delay timer sets the amount of time to delay between 
polls of active tributaries. 

• Scheduling timer. The scheduling timer sets the time limit between 
recalculations of tributary polling priorities. 

• Stream timer. The stream timer sets the amount of time that a tributary or 
half-duplex remote station is allowed to hold the line. 

The DMP11 automatically handles message retransmission for normal 
operations. However, when a DDCMP circuit is in the SERVICE state, a 
line retransmission timer is necessary because the DMP11 does not handle 
retransmission in maintenance operation protocol (MOP) mode. 
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You can determine the optimum value to use for the retransmit timer for a 
synchronous DDCMP line. The formula involves a constant obtained from 
the calculation of the time required for transmission and reception of the 
contents of a single executor buffer over the line. To derive the constant, 
multiply the executor buffer size (in bytes) by 8 bits/byte, divide the result 
by the line speed (in bits per second), and multiply by 2 (for transmission 
and reception). To this result, add a factor representing the time allotted for 
transmission delay and processing overhead (for DDCMP lines, a factor of 
1/2 is used). Convert the final value to milliseconds by multiplying by 1000 
ms/sec. When the constants are multiplied out, the remaining constant is 
20,000, which applies to the following retransmit timer calculation. 

In general, use this formula to calculate the best value for the retransmit timer 
(in milliseconds): 

RETRANSMIT TIMER = (20000 * buffer-size * number-of-buffers)/bps-of-line 

The number of buffers is the value specified for the MAXIMUM TRANSMITS 
parameter in the SET CIRCUIT command; it represents the maximum number 
of data messages that the tributary can transmit in a single poll interval (see 
Section 3.5.3.2). 

Assume an example with an executor buffer size of 576, a line of 56K bits per 
second (bps), and four buffers per selection interval. The formula would be 
calculated as shown below. 

RETRANSMIT TIMER = (20000 * 576 * 4)/56000 * 820 milliseconds 

To set a retransmit timer for a DDCMP line, use the RETRANSMIT TIMER 
parameter, as shown below. 

NCP>SET LINE DMP-2 RETRANSMIT TIMER 820 

This command sets the retransmission frequency for line DMP-2 to 820 
milliseconds. If a message is not acknowledged in 820 milliseconds, it will be 
retransmitted. 

The above formula does not apply to the DMF32 tributary mode. The value 
of the retransmit timer is the maximum time the tributary will hold the 
line before returning control to the control station. For DMF32 tributary 
mode, therefore, the more active the tributary, the higher the value to which 
you should set the retransmit timer (a value of 2000 is recommended). For 
inactive tributaries, set the timer value lower (a value of 500 milliseconds is 
recommended). 


3.6.3.4 Satellite Transmission Control 

For a connection over a very long path, such as a satellite link, use the 
TRANSMIT PIPELINE parameter to establish the maximum number of 
DDCMP messages that may be transmitted over a DMR11 line without 
waiting for a positive acknowledgment from the remote node. This parameter 
is useful for satellite transmissions because of the long round-trip delay 
between message transmission and acknowledgment. For example, the 
following command sets a maximum of 10 DDCMP messages for the line 
DMC-2: 

NCP>SET LINE DMC-2 ... TRAMSMIT PIPELINE 10 

The TRANSMIT PIPELINE parameter is optional and, by default, takes the 
value 7. 
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Because of the system memory overhead involved, you should avoid 
arbitrarily setting this value higher than necessary. The optimum value 
for the TRANSMIT PIPELINE parameter for the DMR11 is equal to the 
number of DDCMP messages that can be transmitted before the first message 
in the sequence is acknowledged. You can calculate the optimum TRANSMIT 
PIPELINE value using the algorithm 

messages = (delay*rate)/(size*8) 

delay The link's round trip delay time in seconds, which is the total 

time required for a message to reach the remote receiver and 
for the acknowledgment to be received by the transmitter. 
You can determine the delay value from information supplied 
by the carrier providing the leased circuit, or by observing 
the delay on suitable line monitoring equipment. 

rate The line speed in bits per second. 

size The average DDCMP message size in bytes, which can be 

calculated by dividing the number of bytes transmitted by 
the number of messages transmitted. Use the SHOW LINE 
command with the COUNTERS parameter to determine the 
number of bytes and messages transmitted. Line counters 
are described in Section 3.6.6. 

For example, to determine the optimum TRANSMIT PIPELINE value of a 
satellite link that has a round trip delay of 0.67 seconds, a line speed of 9.6K 
bits per second, and an average DDCMP message size of 40 bytes, calculate 
the following: 

(0.67*9600)/(40*8) = 20 

Therefore, for this example, the optimum value for TRANSMIT PIPELINE is 
20 messages. 


3.6.3.5 Asynchronous DDCMP Line Parameters 

The LINE SPEED, HANGUP, and SWITCH parameters apply only to 
asynchronous DDCMP lines. Values for these parameters are provided 
automatically when a line is switched dynamically from a terminal line to 
an asynchronous DDCMP line. When you initiate a dynamic connection 
between two nodes over a telephone line, these parameters are included 
in the line entries NETACP supplies to the NCP database. For static 
asynchronous DDCMP lines, these parameters usually assume their default 
values. 

The LINE SPEED parameter specifies in baud the speed of an asynchronous 
DDCMP line. The parameter defaults to the current speed of the line. If two 
asynchronous lines are connected, both lines must have the same line speed. 
If a dynamic connection is made, this value is supplied automatically for each 
line. For a static asynchronous line, the default line speed value is the value 
of the /SPEED qualifier in the DCL command SET TERMINAL you specified 
to cause the terminal line to be converted to an asynchronous line. 

The HANGUP parameter determines whether the modem signal is dropped 
when the line is shut down. When you shut down a dynamically switched 
asynchronous line, the modem carrier will be dropped if the value of the 
parameter is HANGUP ENABLED. This value, supplied automatically, 
corresponds to the /HANGUP qualifier in the SET TERMINAL command 
you specified to cause the terminal line to be switched to an asynchronous 
line. If the value supplied for the parameter is HANGUP DISABLED, the 
modem signal will not be dropped when the line is shut down. For a static 
asynchronous line, the parameter defaults to HANGUP ENABLED. 
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The SWITCH parameter indicates whether an asynchronous DDCMP line 
is to be switched back to a terminal line after it is disconnected from the 
network (when the channel to the network is deassigned). The SWITCH 
parameter is enabled automatically for a dynamic asynchronous line so 
that the line can be switched back to a terminal line when the dynamic 
connection is broken. The parameter defaults to SWITCH DISABLED for a 
static asynchronous line, which remains available as a communications line 
even when not assigned a channel to the network. Generally, the user does 
not need to set the SWITCH parameter manually. 


3.6.4 Ethernet Line Parameters 

Ethernet lines do not support any service functions. Parameters the Ethernet 
lines have in common with other DECnet lines are the COUNTER TIMER, 
PROTOCOL, STATE, and BUFFER SIZE parameters. The BUFFER SIZE 
parameter can be used to optimize performance over a high-speed data link 
such as an Ethernet (see Section 3.6.2.2). 

The Ethernet address associated with the Ethernet line device hardware is 
displayed as a read-only parameter, HARDWARE ADDRESS, in response to 
the SHOW LINE command. The command 

NCP>SHOW LINE UNA-0 CHARACTERISTICS 

will result in the following information being displayed for UNA-0: 

Protocol = Ethernet 

Hardware address = AA-00-03-00-00-0C 

See the discussion of Ethernet physical addresses in Section 2.1.1, and the 
general description of the format of Ethernet addresses in Section 3.3.4. 


3.6.5 X.25 Line Parameters 

All X.25 lines must specify the LAPB or LAPBE protocol. The line parameters 
unique to X.25 lines include the MAXIMUM RETRANSMITS, MAXIMUM 
BLOCK, and MAXIMUM WINDOW parameters. 


3.6.5.1 Frame Control for X.25 Lines 

The MAXIMUM BLOCK and MAXIMUM RETRANSMIT parameters control 
the size and transmission of frames over an X.25 line; the RETRANSMIT 
TIMER and MAXIMUM RETRANSMIT parameters control the retransmission 
of frames. The MAXIMUM WINDOW parameter controls the number of 
frames for which outstanding acknowledgments are allowed. 

Use the RETRANSMIT TIMER parameter to control the frequency of frame 
retransmission at X.25 level 2 on LAPB and LAPBE lines. For example, the 
command below sets the retransmission frequency to 2000 milliseconds for 
the line DUP-0: 

NCP>SET LINE DUP-0 ... RETRANSMIT TIMER 2000 ... 

In other words, if a frame is not acknowledged in 2000 milliseconds, it is 
retransmitted. 

The value for this parameter depends on the size of the frame and the speed 
of the X.25 line; refer to the VAX PS1 Public Network Information Cards for 
recommended values. Specify a value in the range 1 to 65,535. 
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The RETRANSMIT TIMER parameter is optional and, by default, takes the 
network value. Refer to the VAX PSI Public Network Information Cards for the 
network value of this parameter. 

To specify the maximum number of times a frame is retransmitted over 
a specified X.25 line, use the MAXIMUM RETRANSMITS parameter. 

For example, the following command indicates that if a frame is not 
acknowledged in 2000 milliseconds it is retransmitted and that this operation 
is to be performed a maximum of 10 times: 

NCP>SET LINE DUP-0 ... RETRANSMIT TIMER 2000 - 
_ MAXIMUM RETRANSMITS 10 ... 

Specify a value in the range 1 to 255. 

The MAXIMUM RETRANSMITS parameter is optional and, by default, takes 
the network value. Refer to the VAX PSI Public Network Information Cards for 
the network value of this parameter. 

To specify the maximum size of the frame for a particular X.25 line, use the 
MAXIMUM BLOCK parameter. For example, the following command sets the 
size of the frame to 133 bytes for the line DUP-0: 

NCP>SET LINE DUP-0 ... MAXIMUM BLOCK 133 ... 

Produce a limit for the frame size as follows: 

1 Calculate the maximum packet size and add five bytes. 

2 If you subscribe to the LABPE protocol, add one byte to this total. 

3 If you subscribe to extended sequence numbering at level 3, add another 
byte to the total. 

4 If you subscribe to the fast select facility and the current total is less than 
213 bytes, replace the current total with 213 bytes. 

The maximum frame size you specify should be greater than the total you 
have calculated and less than or equal to 4103 bytes. 

Note that some communications devices limit the frame size. This may cause 
errors, even if you follow the preceding rules. For more details refer to the 
VAX PSI documentation set. 

The MAXIMUM BLOCK parameter is optional and, by default, takes the 
network value. Refer to the VAX PSI Public Network Information Cards for the 
network value of this parameter. 

To specify the maximum number of frames for which there are outstanding 
acknowledgments for a particular X.25 line, use the MAXIMUM WINDOW 
parameter. For example, the command below sets the maximum to 2 for the 
line DUP-0: 

NCP>SET LINE DUP-0 ... MAXIMUM WINDOW 2 ... 

The MAXIMUM WINDOW parameter is optional and, by default, takes the 
network value. Refer to the VAX PSI Public Network Information Cards for the 
network value of this parameter. 
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3.6.5.2 Receive Buffers for X.25 Lines 

Optionally specify the number of buffers in the receive queue of any X.25 
lines. Use the RECEIVE BUFFERS parameter, for example: 

NCP>SET LINE DUP-0 ... RECEIVE BUFFERS 4 ... 

Specify a value in the range 2 to 32. By default, the number of buffers is 3. 
This value is normally adequate for DUP, DPV, and DMF lines. For KMX, 
KMY, and KMV lines, a value of 8 is recommended. 


3.6.5.3 Interface of X.25 Lines 

The INTERFACE parameter specifies whether the line will operate as a DTE 
or as a DTE. It can take the values DTE or DCE. For example: 

NCP>SET LINE DUP-0 ... INTERFACE DCE 

DTE is the default. 

Note that you can only use the DCE interface in conjunction with the 
ISO8208 network profile. 


3.6.5.4 Network for X.25 Lines 

The NETWORK parameter specifies the network to which the line will 
connect. For example: 

NCP>SET LINE DUP-0 ... NETWORK TELENET1 

If more than one network is available, this parameter is mandatory. 


3.6.6 Line Counters 


DECnet software automatically maintains statistics for certain lines in the 
network. These statistics are known as line counters. Line counters for 
DDCMP lines include the number of bytes and data blocks sent and received; 
local and remote process errors; and the amount of time since the counters 
were last zeroed. DECnet-VAX currently maintains these counters only 
for DMP11 and DMF32 lines. Line counters for Ethernet lines include the 
number of bytes, multicast bytes, data blocks, and multicast blocks sent 
and received; the number of blocks deferred or sent after collision; and the 
number of send failures and discarded frames. This counter information 
may be useful alone or in conjunction with logging information to measure 
the performance and throughput for a given line. Refer to Section 2.9 for a 
discussion of logging. 

VAX PSI automatically maintains statistics for X.25 lines in the network. 
These statistics are also called line counters, but are used for X.25 lines only. 
Such information may include bytes and data blocks sent and received; 
inbound and outbound data errors; and remote and local reply timeouts, 
buffer errors, and process errors. These counters, together with component 
characteristics, are useful in monitoring the activity of X.25 lines. The 
counters may, for example, be employed to measure the performance and 
throughput of a given X.25 line. 

You can use NCP to affect the frequency with which counters are logged 
and when the counters are zeroed. At any point while the network is 
running, you can also display line counter statistics using the SHOW LINE 
COUNTERS command. 
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To set a timer whose expiration automatically causes the line counters to 
be logged at the logging sink (location) and then zeroed, use the SET LINE 
command with the COUNTER TIMER parameter. The command below 
causes a line counter logging event to take place every 600 seconds. 

NCP>SET LINE DMC-0 COUNTER TIMER 600 

To clear this parameter, use the NCP command 

NCP>CLEAR LINE DMC-0 COUNTER TIMER 

At any point when the network is running, you can zero line counters for a 
given line or for all known lines. Use the following commands to zero line 
counters: 

NCP>ZER0 LINE DMC-0 COUNTERS 
NCP>ZER0 KNOWN LINES COUNTER 


3.7 Routing Commands 

As network or system manager, you can use certain NCP command 
parameters to specify how the network is to be configured into routing and 
nonrouting nodes and into areas. Other NCP parameters indirectly control 
the path data takes through the network, and control the timing of routing 
messages; these parameters have reasonable default values for most networks. 
If the network is very large, it may be helpful to have a network manager, 
rather than individual system managers, be responsible for controlling the 
flow of data through the network. 


3.7.1 Specifying the Node Type 

The type of node is specified in the TYPE parameter of the DEFINE 
EXECUTOR command. DECnet-VAX supports three values for the node¬ 
type: NONROUTING IV, ROUTING IV, and AREA. The type of a Phase 
IV end node is NONROUTING IV, the type of a Phase IV level 1 router 
is ROUTING IV, and the type of a Phase IV level 2 router is AREA. For 
example, to designate the executor as a Phase IV nonrouting node (end node), 
specify 

NCP>DEFINE EXECUTOR TYPE NONROUTING IV 

To specify the executor as a level 2 router in an area network configuration, 
enter 

NCP>DEFINE EXECUTOR TYPE AREA 

The default value for node-type depends on the particular type of DECnet- 
VAX license key installed (see Section 2.4.1.1). If the key is for a full function 
license (supporting routers and end nodes), the default value of the TYPE 
parameter is ROUTING IV; if the key is for an end node license, the default 
(and only value possible) is NONROUTING IV. 

Note that you cannot change the executor node type while DECnet is 
running. You must shut down the network, use the DEFINE command to 
change the executor node type, and then restart the network. 

The SHOW EXECUTOR CHARACTERISTICS command displays the node 
type of the executor node. The SHOW NODE STATUS command displays 
the node type of a specified adjacent node. The possible values of node-type 
are area, routing IV, nonrouting IV, routing III, nonrouting III, or phase II. A 
Phase IV node can be a level 2 router (area), a level 1 router (routing IV), or 
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an end node (nonrouting IV). A Phase III node can be either a router (routing 
III) or an end node (nonrouting III). 


3.7.2 Specifying the Area Number in a Node Address 

To configure a network for area routing, assign each node to a specific area 
which has a unique number. The area number is a decimal number, in the 
range 1 through 63, which appears as a prefix on the decimal node number of 
the individual node. The node number must be unique within the area. The 
maximum value for node number is 1032. The area number and the node 
number are separated by a period. The format of a node address in an area 
network is 

area-number.node-number 

For example, node 300 in area 40 has an node address of 40.300. 

To set the node address for the local node in an area configuration, use the 
SET EXECUTOR command with the ADDRESS parameter, as below. 

NCP>SET EXECUTOR ADDRESS 40.300 

Configuration of a network requires that each node be assigned a node 
address containing an appropriate area number. If you do not specify an area 
number in a node address, the executor area number is used. 

A Phase IV node address can be converted to a decimal equivalent for use 
in DCL commands, such as COPY, and in sending messages using the Mail 
Utility. The algorithm to convert the address to its decimal equivalent is 

(area-number * 1024) + node-number 

The address can also be converted to its hexadecimal equivalent for 
incorporation in the Ethernet physical address of the node (see Section 3.3.4). 

It is generally more convenient to refer to a node by name. 


3.7.3 Setting Routing Configuration Limits 

During configuration of the network, you can establish certain limits related 
to routing over the network. You can limit the number of routers allowed 
on a single Ethernet and the number of routing and end nodes permitted on 
all Ethernet circuits to which the local node is attached. If the network is 
grouped into areas, you can limit the number of areas allowed. 


3.7.3.1 Maximum Number of Ethernet Routers and End Nodes Allowed 

Certain NCP command parameters limit the number of routers and end 
nodes that can be configured on Ethernet circuits. Use the SET CIRCUIT 
command with the MAXIMUM ROUTERS parameter to set the maximum 
number of routers permitted on a particular Ethernet circuit. The largest 
number of routers allowed on an Ethernet is 33, which is the default value 
of the MAXIMUM ROUTERS parameter. Note that the recommended limit 
on the number of routers on a single Ethernet circuit is 10, because of the 
control traffic overhead (routing messages and system identification messages) 
involved. For example, the following command specifies that no more than 
five routers can exist on Ethernet circuit UNA-0. 

NCP>SET CIRCUIT UNA-0 MAXIMUM ROUTERS 5 
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Use the SET EXECUTOR command with the MAXIMUM BROADCAST 
ROUTERS parameter to specify the maximum number of routing nodes that 
will be permitted on all Ethernet circuits to which the local node is attached. 
Each routing node can be either a level 1 router (capable of routing within its 
own area, if area routing is specified) or a level 2 router (capable of routing 
within its own area and outside of its area). For example, the following 
command specifies that a maximum of 12 routers is allowed on Ethernet 
circuits to which the executor node is connected: 

NCP>SET EXECUTOR MAXIMUM BROADCAST ROUTERS 12 

The default value of this parameter is 32. 

Use the SET EXECUTOR command with the MAXIMUM BROADCAST 
NONROUTERS parameter to set the maximum number of nonrouting nodes 
(end nodes) permitted on all Ethernet circuits to which the local node is 
attached. For example, the following command specifies that no more than 
20 end nodes can exist on all Ethernet circuits to which the executor node is 
connected. 

NCP>SET EXECUTOR MAXIMUM BROADCAST NONROUTERS 20 

The default value is 64. 


3.7.3.2 Maximum Number of Areas Allowed 

When configuring an area network, use the SET EXECUTOR command with 
the MAXIMUM AREA parameter if you want to set a limit on the number of 
areas that the executor node's Routing layer will recognize. For example, if 
you want a maximum of 50 areas to be recognized, specify the command 

NCP>SET EXECUTOR MAXIMUM AREA 50 

If this parameter is not specified, the Routing layer will recognize up to 63 
areas. 


3.7.4 Routing Control Parameters 

NCP supports routing parameters that provide for circuit cost control (COST), 
control of the total path between any two nodes (MAXIMUM COST, 
MAXIMUM HOPS), and route-through control (MAXIMUM VISITS). For 
a network divided into areas, the routing parameters for maximum cost 
and length of the paths between areas in the network (AREA MAXIMUM 
COST, AREA MAXIMUM HOPS) also apply. These parameters are used to 
control the path that data is likely to take when being transmitted through 
the network, and to minimize congestion at particular nodes in the network. 
For most networks, the default values of these parameters are reasonable. 


3.7.4.1 Circuit Cost Control Parameter 

Figure 3-2 illustrates sample circuit costs attributed to the network example. 
The following paragraphs discuss routing control parameters as they relate to 
Figure 3-2. 

The COST parameter in the SET CIRCUIT command specifies the circuit cost. 
For example, the following command sets a cost for the circuit connecting 
node BOSTON to node NYC: 

NCP>SET CIRCUIT DMC-2 COST 1 

This command sets a low cost for the circuit. Numbers in the range of 1 to 25 
are valid circuit costs. The default value is 10. 
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Figure 3-2 Network Circuit Costs 


DENVER 


BANGOR 



BOSTON 


NYC 


ZK-1866-84 


It is recommended that you establish a circuit cost standard that is uniform 
across the entire network. The following algorithm is used to determine 
appropriate circuit costs. The algorithm is based on circuit delay. Delay is 
based on circuit bandwidth. 

1 where the bandwidth is greater than 100K bits per second 

x where x is approximately equal to 100,000 divided by the bandwidth, and 

where the bandwidth is greater than 4K bits per second but less than 100K 
bits per second 

25 where the bandwidth is less than 4K bits per second or the circuit is an 
X.25 circuit 
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3.7.4.2 Maximum Path Control Parameters 

Both the maximum cost for all circuits to the destination node (MAXIMUM 
COST) and the maximum hops that a packet can make when routed to the 
destination node (MAXIMUM HOPS) are set using the SET EXECUTOR 
command. These parameters are used to ascertain whether a destination is 
reachable. The value of the MAXIMUM HOPS parameter should always be 
equal to or greater than the longest possible path within the network. For 
the network example, a maximum hop parameter value of 6 is sufficient. 

The maximum cost and hops values should be chosen carefully, with regard 
to the intended use of the network, the actual network configuration, and 
possible failures. The default values of these parameters are reasonable for 
most networks. 

The following example indicates the use of the SET EXECUTOR command to 
specify the maximum cost and hops allowed for network routing. 

NCP>SET EXECUTOR MAXIMUM COST 100 MAXIMUM HOPS 6 

Values in the range 1 to 1022 are valid for the MAXIMUM COST parameter; 
the default value is 1022. Values in the range 1 to 30 are valid for the 
MAXIMUM HOPS parameter; the default value is 30. The value for the 
MAXIMUM HOPS parameter must be less than or equal to the value for 
MAXIMUM VISITS. Use as small a number as possible in these ranges. 

Figure 3-2 illustrates the relationship between circuit costs and path costs. 

To send a packet from TRNTO to DALLAS, the system can route it over 
one of two paths, both of which require two hops; the first path is through 
BOSTON, the second through DENVER. However, because the path through 
BOSTON has a cost of 8 and the path through DENVER has a cost of 5, the 
system will route the packet through DENVER. 

Under normal conditions, a MAXIMUM HOPS value of 3 would be sufficient 
for the network in Figure 3-2. However, if the MAXIMUM HOPS value 
were set to 3, a failure of the TRNTO-BOSTON circuit would render TRNTO 
unreachable from NYC, KANSAS, or BANGOR, even though a physical 
path still exists (the four-hop path NYC-BOSTON-DALLAS-DENVER- 
TRNTO). Consideration of possible failures is also important in establishing 
the MAXIMUM COST parameter. 


3.7.4.3 Route-Through Control Parameter 

The MAXIMUM VISITS parameter in the SET EXECUTOR command specifies 
the maximum number of nodes a packet can be routed through before 
arriving at the destination node. For example, the following command sets 
the number of visits to 12: 

NCP>SET EXECUTOR MAXIMUM VISITS 12 

If the number of nodes that the data packet visits exceeds the value of 
MAXIMUM VISITS, the packet is discarded. Generally, use a value that 
is two or three times the value for the MAXIMUM HOPS parameter. At a 
minimum, the value for the MAXIMUM VISITS parameter must be equal to 
or greater than the value for the MAXIMUM HOPS parameter. The maximum 
value is 63, which is also the default value. 
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3.7.4.4 Area Path Control Parameters 

When a network is divided into areas, the MAXIMUM COST and MAXIMUM 
HOPS parameters described above are used to control the path between each 
pair of nodes within each area. A second set of routing parameters (AREA 
MAXIMUM COST, AREA MAXIMUM HOPS) is used to control the total cost 
and length of paths between level 2 routers within the whole network. In 
effect, these parameters control the total possible path between areas in the 
network. 

The AREA MAXIMUM COST parameter in the SET EXECUTOR command 
specifies the limit on the total path cost between the local level 2 router and 
any level 2 router in the network. This value is the maximum cost of circuits 
on the longest path between Level 2 routers. The AREA MAXIMUM HOPS 
parameter in the SET EXECUTOR command specifies the maximum number 
of hops that a packet can make between the local level 2 router and any 
other level 2 router in the network. The AREA MAXIMUM COST and AREA 
MAXIMUM HOPS parameters are used to determine whether an area is 
reachable. The default values for these parameters are reasonable. Selection 
of other values should be made carefully, with regard for the level 2 (area) 
topology of the network. 

The following example illustrates the use of the SET EXECUTOR command 
to specify the maximum cost and hops permitted for routing between level 2 
routers in the network: 

NCP>SET EXECUTOR AREA MAXIMUM COST 500 AREA MAXIMUM HOPS 10 

Values in the range 1 to 1022 are valid for the AREA MAXIMUM COST 
parameter; the default value is 1022. Values in the range 1 to 30 are valid for 
the AREA MAXIMUM HOPS parameter; the default value is 30. 


3.7.5 Routing Message Timers 

Routing messages exchanged between adjacent nodes contain information 
about the cost and hops to each node in the network. Routing update 
messages are sent automatically whenever there is a change in the 
information (for example, when a line goes down). Nodes that detect the 
change (for example, nodes at each end of a line that failed) are the first 
to send routing update messages. The changed routing information then 
propagates as far as necessary to update all routers. 

Routing updates are also sent periodically under control of the routing timers. 
These periodic transmissions ensure that routing tables are kept up to date 
even in the unlikely event that a routing update message is lost. 

The timer for transmission of routing messages is set using the SET 
EXECUTOR command. For nodes on non-Ethernet circuits, the timer is 
called the routing timer. Changing the setting of the routing timer will cause 
additional routing messages to be transmitted to all adjacent nodes from 
the local node, at a specified interval. For example, this command sets the 
frequency of transmission of routing messages to 240 seconds: 

NCP>SET EXECUTOR ROUTING TIMER 240 

When this timer expires, the local node sends a routing message to all 
adjacent nodes. Numbers in the range of 1 to 65,535 are valid for the 
ROUTING TIMER parameter; the default value is 600. It is recommended 
that you allow NETACP to supply the default. 
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For a node on an Ethernet circuit, the timer is called the broadcast routing 
timer. When the timer expires, the local node sends a multicast routing 
configuration message to all nodes on the Ethernet. For example, this 
command sets the frequency of routing message transmissions to 30 seconds: 

NCP>SET EXECUTOR BROADCAST ROUTING TIMER 30 

The broadcast routing timer for a node on an Ethernet circuit is set to a 
much lower value (approximately 30 to 40 seconds) than the routing timer 
for a node on a non-Ethernet circuit (every few minutes). Ethernet routing 
messages are sent more often so that full routing messages can be exchanged 
in case of datagram loss. The default value for this parameter is 40. 


3.7.6 Cl End Node Circuit Failover 

If a VAXcluster that uses the Cl as its DECnet datalink is configured to include 
end nodes as well as routers, it is possible to define a backup circuit in each 
end node that takes over should the primary circuit connecting the end node^ 
to its router fail. 

An example is a three-node cluster comprised of one router (R) and two end 
nodes (El and E2). Each end node should have a circuit defined to the router. 
It is possible to define a second circuit in each end node which connects to 
the other end node. The backup circuit is defined with a higher cost than the 
primary circuit, and its state is set on. Under normal circumstances, with all 
three nodes operational, the lower cost circuit (to the router) is used. Should 
the router shut down, this circuit will be shut down. The backup circuit will 
become the lowest cost circuit in the ON state, and will be used. The backup 
circuit allows the end nodes to communicate while the router is absent from 
the cluster. 

If nodes El, E2, and R have Cl port addresses 1, 2, and 3, respectively, this 
topology could be defined as follows in node El: 

NCP>DEFINE CIRCUIT Cl-0.3 TRIBUTARY 3 COST 1 STATE ON 
NCP>DEFINE CIRCUIT CI-0.2 TRIBUTARY 2 COST 10 STATE ON 

The first circuit is the primary circuit; the second circuit is the backup circuit. 

This technique can be extended to a larger cluster with two routers and 
several end nodes; in each end node, two circuits of different cost are defined, 
one to each router. The network could then survive the failure of one router, 
but not both. 


3.8 Logical Link Commands 

Use the SET EXECUTOR command to set logical link parameters that define 
the maximum number of active links permitted and set the timers that control 
NSP operation. Use the DISCONNECT LINK command to disconnect links 
while the network is running. 
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3.8.1 Maximum Number of Links 

When defining parameters for the local node, you may specify the maximum 
number of logical links that can be active for that node. DECnet-VAX uses 
this value to determine the size of internal data structures. The command 
below sets the maximum number of links at 30: 

NCP>SET EXECUTOR MAXIMUM LINKS 30 

Note that this value includes both inbound and outbound logical links. In 
the example above, you can have only 15 links if both ends of all links are 
terminated locally. 

If an alias node identifier has been established, you may also specify the 
maximum number of logical links that can be active at the local node using 
the alias node identifier. For example, the following command sets the alias 
maximum links at 40. 

NCP>SET EXECUTOR ALIAS MAXIMUM LINKS 40 

When a VAXcluster uses an alias node identifier, two kinds of links (alias 
node and local node) are possible. These links are controlled by the 
appropriate parameter, MAXIMUM LINKS or ALIAS MAXIMUM LINKS. 
When both of these parameters are specified, the upper limit on the number 
of logical links that use the individual node identifier is reduced. Refer to the 
VAX/VMS Network Control Program Reference Manual for information about 
logical link restrictions. 


3.8.2 Disconnecting Logical Links 

You can selectively disconnect logical links active on the local node while 
the network is running. The first command below disconnects link 1827; the 
second disconnects all links active with all remote nodes. 

NCP>DISCONNECT LINK 1827 
NCP>DISCONNECT KNOWN LINKS 

Use the SHOW KNOWN LINKS command to obtain link status information, 
including link addresses, and to verify that links have been disconnected 
upon issuing these commands (see Section 3.3). DECnet-VAX maintains and 
uses link addresses. 

Optionally, you can disconnect a single link or all known links to a particular 
node. For example, the following NCP command disconnects all links to 
node TRNTO: 

NCP>DISCONNECT KNOWN LINKS WITH NODE TRNTO 


3.8.3 Logical Link Protocol Parameters 

A variety of parameters exists for controlling NSP-related logical link activity. 
These parameters regulate the bounds for NSP connect sequences, inactivity 
intervals, and message retransmission. Another parameter limits the amount 
of nonpaged pool NSP will use for logical link transmission. You can change 
these parameters at any time, without affecting existing logical links. 
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3.8.3.1 Incoming and Outgoing Timers 

There are two timers that regulate NSP connect sequences: an incoming timer 
and an outgoing timer. Use the INCOMING TIMER parameter to specify 
the maximum duration between the moment that a logical link connection 
is received for a process on the local node and the moment that the process 
accepts or rejects the connection. It is recommended that you use a value 
between 30 and 60. To allow 30 seconds for connection confirmation, use the 
following command: 

NCP>SET EXECUTOR INCOMING TIMER 30 

Expiration of this timer signals that a timeout has occurred. In effect, this 
timer protects the local node against a process that never responds to an 
inbound connection request. 

The OUTGOING TIMER parameter specifies a timeout value for the duration 
between the time a connection is requested and the time it is acknowledged 
by the destination node. It is recommended that you use a value between 
30 and 60. For example, this command allows 30 seconds to elapse before a 
timeout is assumed to have occurred: 

NCP>SET EXECUTOR OUTGOING TIMER 30 

A typical value for this timer ranges from 10 to 90 seconds, depending on 
line speed and network diameter. The network diameter is the maximum 
diameter over the set of shortest paths between all pairs of nodes in the 
network. In effect, this timer protects the user on the local node against a 
connection request that never completes. 


3.8.3.2 Inactivity Timer 

A logical link is inactive when no data is transmitted in either direction for 
a given interval of time. The inactivity timer regulates the frequency with 
which local DECnet software tests the viability of an inactive link, thereby 
protecting the user against a link that may be permanently unusable. Use 
the INACTIVITY TIMER parameter to specify the maximum duration of 
inactivity before the local node tests the viability of the link. For example, 
this command sets the inactivity interval to 60 seconds: 

NCP>SET EXECUTOR INACTIVITY TIMER 60 

When this timer expires, DECnet-VAX generates artificial traffic to test 
the link. The timer starts after an incoming message for the link has been 
processed. The timer is reset if any messages are received on the link. 


3.8.3.3 NSP Message Retransmission 

A third group of parameters regulates the frequency of NSP message 
retransmission. These are the DELAY WEIGHT, DELAY FACTOR, and 
RETRANSMIT FACTOR parameters for the local node. Use of default values 
for these parameters is recommended. 

NSP estimates the current delay in the round-trip transmission to a node with 
which it is communicating. The value of the DELAY WEIGHT parameter 
is used to calculate a new value of the estimated round trip delay. The old 
round trip delay is weighted by a function of this statistical factor to calculate 
the new round trip delay. If the delay weight is set high, the retransmit time 
changes slowly. If the weight is set low, the observed round trip time can 
change quickly if the observed round trip delays vary widely, and thus the 
retransmit time can change more rapidly. 

The value of the DELAY FACTOR parameter is multiplied by one-sixteenth 
of the estimated round trip delay time (derived as above) to determine the 
appropriate value for the time to retransmit certain NSP messages. 
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Values in the range of 1 to 255 are used in specifying values for the DELAY 
FACTOR parameter, as in the following example: 

NCP>SET EXECUTOR DELAY WEIGHT 3 DELAY FACTOR 48 

The default value is 80. Refer to the Network Services Functional Specification 
for a complete discussion of these concepts. 

The value of the RETRANSMIT FACTOR parameter regulates the number of 
times NSP will reattempt a transmission when its retransmission timer expires 
for a logical link. This value must be a number in the range of 1 to 65,535; 
the default value is 10. For example, the following command specifies that 
NSP will reattempt a transmission no more than 10 times: 

NCP>SET EXECUTOR RETRANSMIT FACTOR 10 

If NSP tries to retransmit an eleventh time, the logical link will disconnect. 

Note: Unless you have a special need to change the operating characteristics of 
a logical link, you should use the default values for DELAY WEIGHT, 
DELAY FACTOR, and RETRANSMIT FACTOR. In other words, do not 
define these parameters in the permanent database. 


3.8.3.4 Pipeline Quota 

The PIPELINE QUOTA parameter in the SET EXECUTOR command specifies 
the maximum number of bytes NCP will use from nonpaged pool to buffer 
logical-link transmit requests. In effect, this quota determines the number of 
packets NCP will transmit on a single logical link before waiting for a positive 
acknowledgment from the remote end of the link. The number of packets 
is determined by dividing the PIPELINE QUOTA value by the EXECUTOR 
BUFFER SIZE value. 

Unlike previous releases of DECnet-VAX, this PIPELINE QUOTA is not 
deducted from the user process's byte count quota. This change allows the 
system manager to set the process byte count quota to sensible values without 
concern for the nonpaged pool requirements of DECnet. DECnet's nonpaged 
pool usage with respect to the transmission over logical links is bounded by 
the product of the values of the PIPELINE QUOTA and MAXIMUM LINKS 
parameters. 

The following command sets a pipeline quota of 6000 bytes for the local node 
which is using a satellite link: 

NCP>SET EXECUTOR PIPELINE QUOTA 6000 

The default value for PIPELINE QUOTA is currently 3000. If satellite 
communication is being used, it may be necessary to increase this value 
to 6000 or more in order to improve DECnet performance. 


Note: The SET EXECUTOR parameter PIPELINE QUOTA should not be 
confused with the SET LINE parameter TRANSMIT PIPELINE. The 
PIPELINE QUOTA parameter relates to transmission over logical links, 
while TRANSMIT PIPELINE relates to data links. These parameters 
address different levels of the Digital Network Architecture. 
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3.9 Object Commands 

Use the SET OBJECT command to establish and modify the object parameters 
listed in Table 3-6. To remove any or all object parameters from the volatile 
database, use the CLEAR OBJECT command. 


Table 3-6 Object Parameters and Their Functions 


Parameter Function 

Parameter 


Identifies object by number 

NUMBER number 


Identifies command procedure for 
starting the object 

FILE file-id 


Specifies connect privileges for user- 
level access control 

PRIVILEGES privilege-list 

Specifies optional default proxy login 
access control for the object 

f INCOMING 

PROXY J OUTGOING l 
| BOTH 

^ NONE ' 

Determines how the object will 
respond to incoming connect requests 
directed to the alias node identifier 

ALIAS INCOMING j 

DISABLED \ 
ENABLED J 

Associates outgoing connect requests 
for the object with the alias node 
identifier 

ALIAS OUTGOING j 

f DISABLED \ 
l ENABLED J 

Specifies optional default access 
control for inbound connects 

ACCOUNT account 

PASSWORD password 

USER user-id 


3.9.1 DECnet-VAX Objects 

Use the SET OBJECT command to establish and modify certain DECnet-VAX 
objects and their command procedures. 


3.9.1.1 DECnet-VAX Object Identification 

When defining or modifying object parameters, you must identify the name 
of the object. DECnet object names are descriptive alphanumeric strings of 
up to twelve characters in length. DECnet software also uses object numbers 
as unique object identifiers. Object numbers have a range of 1 to 255. Most 
user-defined images will have a 0 object type. However, a user program 
should have a nonzero number assigned when it provides a known service. 
You may define an object name of TASK in the configuration database to 
objects with a 0 object type if you provide additional required privileges or 
default inbound access control to the object. 

Generic objects such as FAL and NML have nonzero object numbers that are 
recognized throughout the network. User-defined images may have unique 
nonzero object numbers; numbers between 128 and 255 are reserved for this 
purpose. For a list of object numbers and their associated names, refer to the 
VAX/VMS Network Control Program Reference Manual. Unlike objects with a 0 
object type, you must set each nonzero object in the configuration database. 
Use the NUMBER parameter to specify a unique object number for nonzero 
objects. For example: 

NCP>SET OBJECT F00 NUMBER 129 


3-70 















Managing and Monitoring the Network 


Note that the object name may not be unique to the generic services specified. 
Only object numbers are unique across systems. For consistency, however, it 
is recommended that you use object names as they are normally referenced 
throughout the network. 

When NETACP receives a logical-link connect request message from a remote 
node, it translates the message into network connect block (NCB) format 
and delivers it to the destination object running on the local node. (Refer to 
Chapter 8 for a description of the NCB.) 


3.9.1.2 Using the Cluster Alias Node Identifier for the Object 

Command parameters for the SET OBJECT and DEFINE OBJECT commands 
specify how certain objects treat incoming and outgoing connect requests 
associated with the alias node. 

By specifying the ALIAS OUTGOING parameter for a particular object, you 
can indicate whether the object uses the alias node address in any outgoing 
connect request. 

This parameter makes it possible to direct an object such as MAIL to use the 
alias node address rather than the executor address for outgoing connections. 
For example, to direct the object FOX to use the alias node identifier for all 
outgoing connect requests, use the following command: 

NCP>SET OBJECT FOX ALIAS OUTGOING ENABLED 

By default, only the object MAIL is so enabled. All other objects are disabled 
unless specified. 

Objects such as PHONE, which use a protocol that depends on multiple links, 
should not have the ALIAS OUTGOING parameter enabled. 

Use the ALIAS INCOMING parameter to specify how certain objects will 
respond to incoming connect requests that are directed to the alias node. 
Specific objects can be either enabled or disabled from receiving these 
incoming connections. 

This parameter allows you to restrict incoming connections to only those 
objects that are appropriate. Any object which can receive multiple incoming 
links or whose resources are not available clusterwide should not be enabled. 
For example, to disallow the object FOO from receiving incoming connect 
requests directed to the alias node address, use the following command: 

NCP>SET OBJECT FOO ALIAS INCOMING DISABLED 

By default, if an alias node identifier has been established for the node, 
ALIAS INCOMING is enabled for all objects except PHONE. If an attempt is 
made to use an alias node address to connect to an object for which ALIAS 
INCOMING has been disabled, the status message NO SUCH OBJECT is 
returned. 
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3.9.1.3 Example of Using the Cluster Alias Node Identifier 

The following scenario illustrates how use of an alias node identifier can 
facilitate communication between a node within a cluster and a remote node. 

A cluster includes nodes THRUSH and ROBIN. The network manager 
establishes a node name CLUSTR in the database using the following DEFINE 
NODE command: 

NCP>DEFINE NODE 2.13 NAME CLUSTR 

To establish the node name CLUSTR as the alias node identification for the 
cluster, the network manager then issues the following command: 

NCP>DEFINE EXECUTOR ALIAS NODE CLUSTR 

Because an alias node identifier has been set, the ALIAS INCOMING 
parameter is enabled by default. This means that all incoming connect 
requests that are addressed to the alias node identifier will be routed to a 
node that uses the alias. 

The network manager also indicates that the MAIL object will use the alias 
node identifier in its outgoing connect requests by specifying the command: 

NCP>DEFINE OBJECT MAIL ALIAS OUTGOING ENABLED 

After the network has been started, a user with the user name Jones logs 
on to node THRUSH. He then sends a mail message to user Smith on node 
BOSTON, which is outside the cluster. Since MAIL is enabled for outgoing 
connect requests, it appears that Jones has sent mail from node CLUSTR. An 
hour later, when user Smith reads her mail from Jones, it is preceded by the 
node-identifier CLUSTR: JONES. 

Smith decides to reply to Jones' mail. She sends the mail message to Jones 
using the destination node CLUSTR. 

Meanwhile, the node THRUSH has been taken down for maintenance, so 
JONES has logged on to node ROBIN. Since ROBIN has also been enabled 
for incoming connect requests addressed to the alias node identifier, JONES 
receives his mail from SMITH. The mail is addressed to CLUSTR::JONES, 
and is delivered to a node that uses the alias. 


3.9.1.4 DECnet-VAX Command Procedure Identification 

For non-zero-numbered objects, the default name of this command file is 
SYS$SYSTEM:objectname.COM. Nonzero objects are identified in the logical 
link connect message only by object number. Therefore, there must be an 
entry in the object volatile database that enables NETACP to locate the 
object name using the object number as a key. When you install DECnet- 
VAX, nonzero object network-defined command procedures are entered by 
default in the SYS$SYSTEM directory, and NETACP knows about these 
command procedures. The supplied command files, named objectname.COM, 
include FAL, HLD, NML, EVL, DTR, MAIL, PHONE, and MIRROR. Except 
for those command procedures supplied by DIGITAL, you must create a 
command procedure for every object that can be started by an inbound 
connection request. You should name command procedures for nonzero 
objects objectname.COM and place them in SYS$SYSTEM. 

For zero-numbered objects, the default name of this command file is 
SYS$LOGIN:objectname.COM. Zero objects are identified in the logical 
link connect message by object name. Therefore, there is no need for an 
entry in the object volatile database. You can, of course, specify an entry in 
the object database at any time. You would be required to include a separate 
entry if you desired special features such as default inbound access control 
information. 
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In either case, you can override the rules for locating the command file by 
explicitly specifying a command procedure file in the SET OBJECT command. 
This file is associated with the object in the object volatile database, as shown 
in the following example: 

NCP>SET OBJECT FAL NUMBER 17 FILE SYS$MANAGER:TRIALFAL.COM 
NCP>SET OBJECT USERS NUMBER 0 FILE SYS$SYSTEM:USERS.COM 

This technique can be particularly useful for zero-numbered objects. The 
command file would then be found in the same place, regardless of which 
access control information you use. If you do not specify the FILE parameter, 
copies of the command file would have to exist in the SYS$LOGIN directory 
of every account in which the object may possibly run. 

Note: Because REMACP is started by a RUN command in RTTLOAD.COM, 

there is no REMACP.COM procedure to start the object, and the software 
does not create a REMACP.LOG file. 

You can also invoke an image directly to serve as a network object, rather 
than using a command procedure. To accomplish this, specify the object file 
name as objectname.EXE, as in the following example: 

NCP>SET OBJECT FAL NUMBER 17 FILE FAL. EXE 

The image should be placed in SYS$SYSTEM. This approach causes the 
object to be started up more quickly; it is useful in cases where no advantage 
is gained by invoking the image from a command procedure. The session log 
will appear as part of the NETSERVER.LOG file. 


3.9.2 VAX PSI Objects 

Use the SET OBJECT command to identify each VAX PSI object, its command 
procedure, and the account information to be used by calls coming in to the 
object from remote DTEs. 


3.9.2.1 VAX PSI Object Identification 

Each object must have a unique name. Object names are descriptive 
alphanumeric strings up to 8 characters in length, for example, OBJONE. 


Use the SET OBJECT command to identify the object. For example: 

NCP>SET OBJECT OBJONE ... 


3.9.2.2 VAX PSI Command Procedure Identification 

The system manager must create a command procedure for every object 
that can be accessed by a destination. Command procedures are named 
filename.COM. 

Use the FILE parameter to specify the command procedure for an object. For 
example: 

NCP>SET OBJECT OBJONE ... FILE STARTUP.COM ... 

The filename is associated with the object identification in the configuration 
database. To allow connections to an object, you must first create a command 
procedure in the default directory for the user account (either specified or 
defaulted) that the incoming call will log in to. The command procedure must 
also exist in the directory of every account in which the associated object 
may run. VAX PSI automatically creates a log file (filename.LOG) every time 
an incoming call causes an object's command file to be executed. This file 
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is created in the default directory of the account. The log file is helpful for 
debugging your own network tasks when an error occurs. 

The command procedure will contain at least a RUN command for an 
image. It may also contain terminal assignments for debugging purposes 
(for example, DBG$INPUT and DBG$OUTPUT). There are no restrictions on 
the type of commands that you can have in this file. 


3.9.2.3 VAX PSI Object Account Information 

The account information that is used by incoming calls from remote DTEs 
should be specified for each object. 

Use the ACCOUNT, PASSWORD, and USER parameters to specify the 
account information. For example: 

NCP>SET OBJECT OBJONE ... USER NET - 
_ PASSWORD NET ACCOUNT PAULS... 

The PASSWORD and USER parameters are mandatory. The ACCOUNT 
parameter is optional and, by default, no account is used. 


3.10 X.25/X.29 Server Module Commands 

The X25-SERVER and X29-SERVER module components handle incoming 
X.25 and X.29 calls from a PSDN. The server components contain records that 
identify destinations for incoming calls and associate with each destination 
parameters that determine whether the destination can handle an incoming 
call. The destination can be on a local DTE connected directly to a PSDN, 
or on a host node to which an X.25 multihost connector node is forwarding 
incoming calls. The server database also specifies the maximum number of 
incoming and outgoing circuits that each module (that is, all destinations for 
that particular module) can have, and specifies the state of the module. 


3.10.1 X25—SERVER and X29—SERVER Module Identification 

Use the SET MODULE X25-SERVER and SET MODULE X29-SERVER 
commands to identify the modules that handle incoming calls. The 
parameters for these two modules are the same. Use separate commands to 
specify the destination qualifier (DESTINATION), and the module parameters 
(MAXIMUM CIRCUITS, STATE, and COUNTER TIMER). 


3.10.2 Destination Identification 

Each destination must have a unique name. Destination names are 
descriptive alphanumeric strings, from 1 to 16 characters in length. Use 
the DESTINATION qualifier to specify the destination name. For example: 

NCP>SET MODULE X25-SERVER DESTINATION JOE ... 

Associate any of the following parameters with each destination: 
SUBADDRESSES, GROUP, CALL MASK, CALL VALUE, CALLED 
ADDRESS, INCOMING ADDRESS, RECEIVING DTE, REDIRECT REASON, 
SENDING ADDRESS, NETWORK, EXTENSION MASK, EXTENSION 
VALUE, PRIORITY, OBJECT, and NODE. 
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The parameters from SUBADDRESSES through EXTENSION VALUE are 
used to determine whether a call is handled. (If you do not specify a 
parameter, the parameter is not used.) The PRIORITY parameter sets the 
priority of the destination, and the OBJECT parameter names the object 
activated when a destination accepts an incoming call. The NODE parameter 
identifies the host node on which the destination is located, if the call is 
received through a local X.25 multihost connector node. 

The parameters are described in the following sections. 


3.10.2.1 DTE Subaddress Range 

Use the SUBADDRESSES parameter to specify a local DTE subaddress or 
a range of subaddresses for each destination. The destination uses this 
information to decide if it can handle incoming calls. 

In the command below, destination JOE will handle only incoming X.25 calls 
that specify local DTE subaddress 35: 

NCP>SET MODULE X25-SERVER DESTINATION - 
JOE SUBADDRESSES 35... 

The following command, however, specifies that destination JOE will handle 
all incoming X.25 calls that specify a local DTE subaddress in the range 12 to 
24 inclusive: 

NCP>SET MODULE X25-SERVER DESTINATION JOE- 
SUBADDRESSES 12-24... 

A subaddress is a decimal integer in the range 0 to 9999. Separate two 
subaddresses with a single hyphen to indicate a range. The second 
subaddress must always be greater than the first. 

The SUBADDRESSES parameter is optional, and, by default, no subaddress 
range is used to determine if the destination can handle an incoming call. 


3.10.2.2 Group Identification 

Use the GROUP parameter to specify a closed user group (CUG) or bilateral 
closed user group (BCUG) name for each destination. The destination uses 
this information to decide if it can handle incoming calls. The following 
command indicates that destination JOE will handle only incoming X.25 calls 
that originate from a DTE that is a member of the closed user group ESECUG: 

NCP>SET MODULE X25-SERVER DESTINATION JOE - 
GROUP ESECUG ... 

The GROUP parameter is optional, and, by default, no group name is used to 
determine if the destination can handle an incoming call. 


3.10.2.3 Remote DTE Identification 

Use the SENDING ADDRESS parameter to specify the remote DTE address 
that sent the call; that is, the address contained in the calling address field in 
the call packet. The DTE address consists of 1 to 15 digits. The destination 
uses this information to decide if it can handle incoming calls. 

As an example, the following command specifies that the destination JOE will 
handle only incoming X.25 calls that come from the remote DTE with address 
987321654: 

NCP>SET MODULE X25-SERVER DESTINATION JOE - 
SENDING ADDRESS 987321654... 








Managing and Monitoring the Network 


3.10.2.4 


3.10.2.5 


The SENDING ADDRESS parameter is optional and, by default, no remote 
DTE address is used to determine if the destination can handle an incoming 
call. 


User Data Field 

Optionally use the CALL MASK and CALL VALUE parameters to specify 
a call mask (to be applied to incoming call data before it is tested) and a 
call value (the string used to test incoming call data). If you specify these 
parameters, VAX PSI extracts the user data from the incoming call request 
and performs a logical AND operation between this data and the call mask. 
VAX PSI then compares the result of this operation with the call value; if the 
fields match, the destination can accept the incoming call. Note that the call 
mask and the call value you specify must be the same length. For example, 
the command below indicates that destination JOE will handle only incoming 
X.25 calls that contain value 11 in their user data fields: 

NCP>SET MODULE X25-SERVER DESTINATION JOE CALL VALUE 11 - 
_ CALL MASK FFFFFFFF ... 

The CCITT (Comite Consultatif International Telegraphique et Telephonique) 
recommends that you use a value of 01 for incoming X.29 calls. As an 
example, the command below indicates that destination JIM will handle only 
incoming X.29 calls that contain 01 in their user data fields: 

NCP>SET MODULE X29-SERVER DESTINATION JIM CALL VALUE 01 - 
_ CALL MASK FF ... 

Specify strings of 2 to 32 hexadecimal digits for the two parameters. 

You can use these two parameters to further identify X.29 calls when the 
terminal user first connects to the PAD (Packet Assembly/Disassembly 
Facility). To do so, specify a destination for the X29-SERVER that recognizes 
a value entered as call data when connecting to the PAD. For example, the 
following command indicates that the destination JANE will handle incoming 
X.29 calls that specified a call data value of A (41 is the hexadecimal value for 
A): 

NCP>SET MODULE X29-SERVER JANE CALL VALUE 0000000041 - 
_ CALL MASK 00000000FF ... 

The CALL MASK and CALL VALUE parameters are optional and, by default, 
no mask or value is used to determine if the destination can handle an 
incoming call. 


Address Extension 

The address extension facility is intended to support end-to-end signaling, 
as described in the VAX PSI Management Guide. Two parameters are used 
for address extension: EXTENSION MASK and EXTENSION VALUE. These 
are used like the CALL MASK and CALL VALUE parameters. The extension 
mask is applied (by VAX PSI) to the called address extension in an incoming 
call and the extension value is compared with the result. For example: 

NCP>SET MODULE X25-SERVER DESTINATION JOE - 
_ EXTENSION VALUE 12340000AA EXTENSION MASK FFFF0000FF 

Here, the destination JOE will handle only incoming calls that have a 
hexadecimal address extension value of 1234, followed by any four digits, 
followed by AA. 
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3.10.2.6 Call Redirection 

The call redirection facility allows you to receive incoming calls that have 
been redirected to your DTE from another DTE connected to the same PSDN. 
Four parameters are used to match redirected calls: REDIRECT REASON, 
CALLED ADDRESS, INCOMING ADDRESS and SENDING ADDRESS. 

The REDIRECT REASON parameter takes one of the following values: 

BUSY Indicates that the called DTE was busy 

OUT OF ORDER Indicates that the called DTE was out of order 

SYSTEMATIC Indicates that calls to the called DTE are automatically 

rerouted 

The CALLED ADDRESS parameter should be matched against the originally 
called address. This will be found in the call redirection notification facility 
field of the call packet. 

The INCOMING ADDRESS parameter should be matched against the address 
in the called address field of the call packet. 

The SENDING ADDRESS parameter (described in Section 3.10.2.3) should be 
matched against the address in the calling address field of the call packet. 

For example: 

NCP>SET MODULE X25-SERVER DESTINATION JOE - 
_ CALLED DTE 123999456 - 
_ INCOMING ADDRESS 123789456 - 
_ SENDING ADDRESS 123888456 - 
_ REDIRECT REASON BUSY 

Here, the destination JOE will handle Calls sent from 123888456 to 123999456 
that have been redirected to 123789456 because 123999456 is busy. 


3.10.2.7 Receiving DTE 

Use the RECEIVING DTE parameter tQ specify the local DTE that has 
received the call. For example: 

NCP>SET MODULE X25-SERVER DESTINATION READINGS - 
_ RECEIVING DTE 234295432 ... 

creates the destination READING6 which matches any calls received on DTE 

234295432. 


3.10.2.8 Priority 

Use the PRIORITY parameter to specify the priority of each destination. If an 
incoming call can be accepted by more than one destination, the destination 
with the highest priority is used. For example, the command below assigns a 
priority of 3 to destination JOE: 

NCP>SET MODULE X25-SERVER DESTINATION JOE PRIORITY 3... 

Specify a priority value in the range 0 to 255, where 255 is the highest 
priority. 

The PRIORITY parameter is mandatory if you specify more than one 
destination that could handle the same incoming call. Otherwise this 
parameter defaults to 0. 
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3.10.2.9 Object Identification 

Use the OBJECT parameter to specify the name of the object that is activated 
when an incoming call arrives and is accepted by the destination. Specify the 
name as an id-string. If the object name is a string of digits, enclose the string 
in quotation marks. You must specify the object itself, using the SET OBJECT 
command (see Section 3.9.1). 

The command below specifies the object OBJONE. 

NCP>SET MODULE X25-SERVER DESTINATION JOE OBJECT OBJONE... 

The OBJECT parameter is mandatory when you specify a destination for the 
first time. 


3.10.2.10 Host Node Identification 

Use the NODE parameter with the DESTINATION qualifier to identify a host 
node on which the destination is located. A host node receives X.25 calls 
that have been forwarded by an X.25 connector node connected directly to a 
PSDN. If your local DECnet-VAX node is configured with VAX PSI software 
in multihost mode to serve as an X.25 connector node, you must specify the 
NODE parameter for each host destination. For example, if your local node is 
a connector node, use the command below to specify that incoming calls are 
to be forwarded to the indicated destination on host node THRUSH on the 
same Ethernet. 

NCP>SET MODULE X25-SERVER DESTINATION THRUSH - 
SUBADDRESSES 1-10 OBJECT 36 NODE THRUSH 

Note that the host node THRUSH must be configured with VAX PSI Access 
software to be associated with the X.25 connector node. The following 
command must be entered at node THRUSH to specify the destination of 
X.25 calls being forwarded by the X.25 connector node. 

NCP>SET MODULE X25-SERVER DESTINATION JOE - 
_ SUBADDRESSES 1-10 OBJECT OBJONE PRIORITY 1 


3.10.3 Maximum Circuits 

Use the MAXIMUM CIRCUITS parameter to specify the maximum number of 
circuits that the module (that is, all destinations) can handle. The command 
below enables the X.25 server module (the call handler for incoming X.25 
calls) to handle a maximum of 32 circuits (incoming and outgoing calls) at 
any one time. 

NCP>SET MODULE X25-SERVER MAXIMUM CIRCUITS 32... 

The MAXIMUM CIRCUITS parameter is optional and, by default, the 
maximum is 255. 
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3.10.4 Operational State of Server 

Use the STATE parameter to specify the operational state of the server 
module. There are three possible states: 

OFF Prevents use of the module and clears all existing virtual circuits 
ON Allows normal use of the module 

SHUT Prevents use of the module for any new activity, but allows existing 
virtual circuits to complete their operation 

The command below allows normal use of the module. 

NCP>SET MODULE X25-SERVER STATE ON ... 

The STATE parameter is optional and, by default, the state is ON. 

For a complete list of states and their transitions, refer to the VAX/VMS 
Network Control Program Reference Manual 


3.11 X.25 Access Module Commands 

The X25-ACCESS module contains the database needed to connect the local 
host node to a DECnet-VAX node serving as an X.25 multihost connector 
node that can access specific PSDNs on behalf of the host nodes. Your local 
host node must be a DECnet-VAX node on which VAX PSI Access software 
is installed. The X.25 connector node must be a VAX/VMS node with VAX 
PSI software in multihost mode installed (or a DECnet Router/X.25 Gateway 
node). Refer to Chapter 5 for an example of the use of NCP commands to 
configure the X.25 connector and host nodes. 

Use the SET MODULE X25-ACCESS command to associate the name of 
the X.25 network you want to access with the name of the node serving 
as the connector to this network. You can optionally specify access control 
information for the link between your host node and the connector node. 


3.11.1 Network Identification in an X.25 Access Module 

Use the NETWORK qualifier in the SET MODULE X25-ACCESS command to 
identify the specific network you want to access through the X.25 connector 
node. The network name you specify must be the same as the one defined in 
the X. 25 protocol module database, at the X.25 connector node. 

The command below identifies the network PSS1 to which the local DECnet- 
VAX node with VAX PSI Access software wants access. 

NCP>SET MODULE X25-ACCESS NETWORK PSS1 ... 

You must specify the NETWORK qualifier and must associate with it the 
NODE parameter. You can optionally specify access control information to be 
used by VAX PSI Access software in connecting to the X.25 connector node. 
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3.11.2 X.25 Connector Node Identification 

Use the NODE parameter to identify the node that will provide connector 
or gateway services to the specified X.25 network. A DECnet-VAX node 
serving as an X.25 connector node must be configured with VAX PSI software 
in multihost mode. The connector node, also referred to as the target node, 
is the one with which the VAX PSI Access software on your local node 
establishes a DECnet link in order to transmit and receive X.25 and X.29 
calls. The following command identifies the node ROBIN as the one which 
will serve as the connector node to permit your local host node to access the 
network PSS1: 

NCP>SET MODULE X25-ACCESS NETWORK PSS1 NODE ROBIN ... 

ROBIN must be a DECnet-VAX node configured with VAX PSI software in 
multihost mode. ROBIN must be connected.by an X.25 line to the PSDN. 
ROBIN must also contain an entry in its X.25 server module database 
indicating that the destinations of specific incoming X.25 calls are located 
on your host node (see Section 2.7). 


3.11.3 Access Control Parameters in an X.25 Access Module 

You have the option of specifying access control parameters to be used by 
the VAX PSI Access software on your local host node in establishing a link 
to the node serving as the X.25 connector. The access control parameters are 
the standard DECnet-VAX parameters: USER, PASSWORD, and ACCOUNT, 
The command below specifies the user identification PSI and password PSI 
the local node can use for an inbound connect when establishing a DECnet 
link with node ROBIN, the X.25 connector to the network PSS1. 

NCP>SET MODULE X25-ACCESS NETWORK PSS1 NODE ROBIN - 
_ USER PSI PASSWORD PSI 


3.12 Logging Commands 

In order to log events, you must turn logging on. (The DECnet-VAX default 
has all events cleared.) To do so, use the SET LOGGING command. Use 
the same command to modify any of the logging parameters. To remove 
any or all parameters from the volatile database, use the CLEAR LOGGING 
command. You must turn the logging state to OFF before attempting to use 
the CLEAR LOGGING command. 

Table 3-7 lists all logging parameters by function, and groups them according 
to operational categories. 
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Table 3-7 Logging Parameters and Their Function 


Parameter Function 


Source-Related Parameter 


Sink-Related Parameter 


Identifies source for events 


Identifies events 


EVENTS event-list 
KNOWN EVENTS 

CIRCUIT circuit-id 


LINE line-id 

MODULE X25-ACCESS 
MODULE X25—PROTOCOL 
MODULE X25-SERVER 
MODULE X29-SERVER 
NODE node-id 


SINK EXECUTOR 
SINK NODE node-id 


Determines location for logging 
events 

Assigns name to logging 
component 

Sets state of logging component 


NAME sink-name 



Source-related and sink-related parameters are mutually exclusive. Therefore, 
you cannot use parameters from both categories in a single command. Use 
the SET LOGGING EVENTS command to specify source-related events, and 
the SET LOGGING STATE command to specify sink-related events. 

For a summary of event class and types and information about the specific 
events that VAX/VMS will log, see the VAX /VMS Network Control Program 
Reference Manual. 

The logging component is defined by the device or process that records 
the events released by the event logger. The logging component can be a 
LOGGING CONSOLE, LOGGING FILE, or LOGGING MONITOR. The 
LOGGING CONSOLE is a terminal or a file that receives events on the sink 
node in a format the user can read. A LOGGING FILE is a user-specified file 
on the sink node. The logging file component receives events in the standard 
DNA binary format. (Refer to the Phase IV Network Management Functional 
Specification for a description of this format.) Instead of specifying the console 
and a file, you can specify a system- or user-supplied LOGGING MONITOR 
program to receive and process DNA format-specific events/ This program 
could possibly receive event data and adapt user application network activity 
to reflect this data. 

If the logging sink is the LOGGING MONITOR, DECnet-VAX uses 
the Operator Communication (OPCOM) facility to display formatted 
event messages on all terminals enabled as NETWORK (using REPLY 
/ENABLE=NETWORK). This generally includes the operator console (OPAO). 
The format of event messages OPCOM displays is similar to that used for 
console logging; however, because of restrictions in the size of messages that 
OPCOM can display, some messages may be truncated slightly, and node, 
circuit, and line counters are not displayed at all. 

To identify the name of the logging component on the local node, use the 
NAME parameter. For example, if the component is a logging console file, 
the command below creates the file EVENTS.LOG into which formatted 
events will be logged. 

NCP>SET LOGGING CONSOLE NAME SYS$MANAGER:EVENTS.LOG 
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To identify a logging monitor program as the logging component, use the 
NAME parameter followed by the program name. See Section 3.12.6. 

Regardless of the logging component you use, parameter selection is the 
same. If you want to modify parameters for all logging on the network, 
then use the plural KNOWN LOGGING component when issuing the SET 
LOGGING command. 

Note: Because console logging uses normal VAX RMS file I/O, if a terminal is 
specified as a sink name, the terminal should not be used or allocated 
for any other purposes. For example, if a user should log in on such a 
terminal, events will be lost until the user logs out. 


3.12.1 Event Identification 

Events are defined by class and type. You can specify the kinds of events to 
be logged by using the following event-list format: 

class.type 

class Identifies the DNA or system-specific layer to which the event pertains 

type Identifies a particular form of event, unique within an event class 

For example, to specify an event in the Routing layer, you would use event 
class 4. The event types for this class range from 0 to 14. Event type 0 
indicates aged packet loss, event type 1 indicates unreachable node packet 
loss, and so forth. Refer to the VAX/VMS Network Control Program Reference 
Manual for a summary of events by class and type. Use the EVENTS 
parameter for the SET LOGGING command to specify those events to be 
logged. If you want to log all event classes and types, use the KNOWN 
EVENTS parameter. When defining the logging component, you must specify 
events to be logged. 

When providing an event list for the EVENTS parameter, you can specify 
only one class for each instance of this parameter. However, several formats 
can define event types for a particular class. You can specify a single event 
type, a range of types, or a combination of the two. The following table 
illustrates these formats. 


Event List Meaning 

4.4 Identifies event class 4, type 4 

4.5-7 Identifies event class 4, types 5 through 7 

4.5,7-9,11 Identifies event class 4, types 5, 7 through 9, and 11. Note that 

types must be specified in ascending order. 


The commands below illustrate invalid event lists. 

NCP>SET KNOWN LOGGING EVENTS 4.4,5.1 
NCP>SET KNOWN LOGGING EVENTS 4.7,3-4,1 

The first example specifies more than one event class. The second example 
specifies event types in numerically descending, rather than ascending, order. 


You can use the asterisk (*) wildcard character in an event list. This character 
can replace only an event type. The following example illustrates the correct 
use of wildcards: 

NCP>SET KNOWN LOGGING EVENTS 2.* 
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This command identifies all event types for class 2 events. 

Two invalid uses of the wildcard character are shown below. 

NCP>SET LOGGING FILE EVENTS *.2-5 
NCP>SET LOGGING FILE EVENTS 4.2-* 

The first command specifies specific event types for all classes. Unless you 
use the KNOWN EVENTS parameter, you can only specify event type 
information for a single class. The second command uses a wildcard to 
specify a partial range of event types. The wildcard character denotes the 
entire range of event types for a given class. 


3.12.2 Identifying the Source for Events 

You can specify the particular source for which events apply, which can be 
either a node, a module, a circuit, or a line. For example, to monitor network 
activity for circuit DMC-0 connected to the local node, use the command 

NCP>SET LOGGING CONSOLE CIRCUIT DMC-0 . . . 

Events that pertain to activity over this circuit will be logged at the console by 
the event logger. The same operation can be performed for any remote node. 
If no source is specified for a component, the event logger logs events for all 
circuits, lines, modules, and nodes known to the local node or DTE. 

Note that you can set only one source (a circuit, module, node, or line) as the 
source for events in a single command. 

The command CLEAR LOGGING KNOWN EVENTS clears only events that 
are not associated with any specific source. To remove an event associated 
with a specific source, use the CLEAR LOGGING command that specifies that 
source. 


3.12.3 Identifying the Location for Logging Events 

Events can be logged either at the local node or a remote node. Use the 
SINK parameter to specify the location. For example, the following command 
routes all event information to the logging monitor program running on node 
DENVER: 

NCP>SET LOGGING MONITOR SINK NODE DENVER . . . 

If you do not specify a location, the local node is the default. 


3.12.4 Controlling the Operational State of Logging 

You can control the operational state of logging only for the local node. There 
are three logging states: 

HOLD Indicates that the sink is temporarily unavailable. Events destined for 
that location are queued. 

OFF Indicates that the sink is unavailable for receiving event information. 
Events will not be logged for that sink. 

ON Indicates that the sink is available for receiving event information. This 

is the normal operational state. 
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Use the STATE parameter to specify the operational state of logging on the 
local node. The command below forces event information to be queued for 
all instances of the logging component on the local node. 

NCP>SET KNOWN LOGGING STATE HOLD 

Note that this control over logging does not affect the operational state of 
the node. It is recommended that you set the default state to ON in the 
permanent database. 

Note: The event logger object (number 26, name EVL) must be specified in the 
object database. If you experience difficulty with event logging, examine 
the event logger's own log file, SYS$MANAGER:EVL.LOG, for possible 
problems. 


3.12.5 Event Logging Example 

The following example illustrates the use of NCP event logging commands. 
You may want to log events normally to OPCOM for each node in the 
network. In addition, you may want each node to transmit its events to a 
single node to be stored in a file. For the three nodes—DENVER, TRNTO, 
and BOSTON—you could issue the following commands at each node to 
accomplish this task. 

At nodes DENVER and BOSTON: 

NCP>SET LOGGING MONITOR STATE ON 

NCP>SET LOGGING MONITOR KNOWN EVENTS 

NCP>SET LOGGING MONITOR SINK NODE TRNTO KNOWN EVENTS 

At node TRNTO: 

NCP>SET LOGGING MONITOR STATE ON 
NCP>SET LOGGING MONITOR KNOWN EVENTS 

NCP>SET LOGGING CONSOLE NAME SYS$MANAGER:NETEVENTS.LOG 
NCP>SET LOGGING CONSOLE STATE ON 
NCP>SET LOGGING CONSOLE KNOWN EVENTS 

Events from all three nodes will be logged to all terminals enabled as 
NETWORK (through the DCL command, REPLY/ENABLE=NETWORK) 
on node TRNTO. In addition, all local events will be logged locally to the file 
NETEVENTS.LOG on node TRNTO. Note that the transmitting node always 
specifies the destination of the event logger output and causes its locally 
generated events to be sent to the receiving sink node to be logged. 


3.12.6 Using a Logging Monitor Program 

Instead of using a logging console or a logging file, you can specify a logging 
monitor program to receive and process events. The logging monitor is 
a system- or user-supplied program. The advantage of using a logging 
monitor program is that it can be tailored to the specific needs of the network 
manager. 

Logging monitor programs can be written in high-level languages and can 
be designed by the programmer to perform specific functions desired by 
the network manager. Thus, the logging monitor program can be simple or 
complex, depending on its design and objective. 
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The following logging monitor example is a BASIC program called 
LOGGER.BAS. It records events released by the event logger and prints 
them to a terminal. Detailed information about the format of the events can 
be found in the Phase IV Network Management Functional Specification. 

10 ! TITLE LOGGER.BAS 

I 

! This is a sample logging monitor program. 

20 MAP (EVENT) & 


BYTE 

FUNCTION.CODE, 

& 

BYTE 

SINK.FLAGS, 

& 

WORD 

EVENT.CODE, 

& 

STRING 

EVENT.TIME = 12, 

& 

WORD 

SOURCE.NODE, 

& 

STRING 

REST = 238 



100 ! Record events released by the network event logger. 

110 OPEN "SYS$NET" FOR INPUT AS FILE #17.. MAP EVENT 
120 ON ERROR GOTO 998 

200 ! Begin loop to extract events and write them to the terminal. 

300 WHILE 1=1 
400 GET #17. 

410 EVENT_CLASS7. = EVENT_CODE / 647. 

420 EVENT_TYPE7. = EVENT.CODE - 327. * (EVENT.CODE / 327.) 

430 EVENT_CLASS$ = NUM1$ (EVENT.CLASS7.) 

440 EVENT_TYPE$ = NUM1$ (EVENT.TYPE7.) 

450 EVENT$ = EVENT_CLASS$ + + EVENT_TYPE$ 

460 PRINT "Event " ; EVENT$ ; " Reported" 

499 NEXT 

998 RESUME 999 

999 END 

To use a logging monitor, you must add the name of the program to the 
object database. For example, the following commands add the executable 
image LOGGER to the database and set LOGGER as the name of the logging 
monitor program. 

NCP>SET OBJECT LOGGER NUMBER 0 FILE LOGGER.EXE 
NCP>SET LOGGING MONITOR KNOWN EVENTS 
NCP>SET LOGGING MONITOR STATE ON 
NCP>SET LOGGING MONITOR NAME LOGGER 

Sample output from logging monitor program (LOGGER.EXE) is as follows: 

Event 0.9 Reported 
Event 0.9 Reported 
Event 4.7 Reported 
Event 4.10 Reported 
Event 4.15 Reported 


3.13 Network Access Control Commands 

The system manager can specify NCP commands to provide for access control 
at the routing initialization level, at the system level during inbound logical 
link connections, and at the node level during inbound and outbound logical 
link connections. You can also use NCP commands to control proxy login 
access to individual accounts and network objects at the local node. This 
section indicates the NCP commands and parameters that can be specified for 
access control. Refer to Section 2.10 for a description of DECnet-VAX access 
control techniques. 
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3.13.1 Specifying Passwords for Routing initialization 

You can specify in your local configuration database transmit and receive 
passwords for each adjacent node. The transmit password is the one you 
send to the remote node and the receive password is the one you expect to 
receive from the remote node during the routing initialization sequence. Use 
the SET NODE command to specify these passwords. Each password can be 
one to eight alphanumeric characters in length. For example, the command 
below establishes transmit and receive passwords for the circuit or circuits 
connecting the local node with node TRNTO. 

NCP>SET NODE TRNTO TRANSMIT PASSWORD VAX.NODE- 
_ RECEIVE PASSWORD VAX.NODE 

If the password contains one or more space characters, you must delimit it 
with quotation marks. 

To remove transmit and receive passwords from the volatile database, use the 
CLEAR NODE command, as shown in the example below. 

NCP>CLEAR NODE TRNTO RECEIVE PASSWORD TRANSMIT PASSWORD 

To provide for increased security when a remote node requests a 
connection over a point-to-point circuit, you can use the circuit parameter 
VERIFICATION INBOUND to prevent your node from revealing its routing 
initialization password while requiring a password from the remote node. 

When two nodes communicate over a point-to-point circuit, only one of the 
nodes can have the VERIFICATION INBOUND parameter set. The primary 
function of this parameter is to permit the system manager to restrict the 
nodes that can initialize over a particular circuit, especially over a dialup 
circuit. 

When a dialup node attempts to establish a dynamic connection with your 
node, the dynamic asynchronous circuit entry is supplied automatically 
to your configuration database. This entry includes the circuit parameter 
VERIFICATION INBOUND, which prevents your node from supplying 
a password to the node requesting a dynamic connection, but requires a 
password from the node dialing in. 

Note that if VERIFICATION INBOUND is specified for a circuit, the node 
parameter INBOUND ROUTER or INBOUND ENDNODE, as appropriate, 
must be specified for the connecting node (see Section 3.13.3). This 
requirement applies to both dynamic and static asynchronous connections. 

If, on the other hand, you are a user on a node with a terminal line (such 
as a Micro VMS system) and you expect to form a dynamic asynchronous 
connection with another node, you should specify a transmit password in 
your node database. For example, if you are at node MYNODE and expect 
to form a dynamic connection with remote node VCLST1 on a VAXcluster, 
specify the following command to establish the transmit password for the 
dynamic circuit: 

NCP>SET NODE VCLST1 TRANSMIT PASSWORD H0MEN0DE1 

The remote node in a dynamic connection must specify the receive password 
it expects to receive from the local node. In the example, the system manager 
at remote node VCLST1 specifies the following command to indicate the 
password expected from node MYNODE: 

NCP>SET NODE MYNODE RECEIVE PASSWORD H0MEN0DE1 
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3.13.2 System-Level Access Control Commands 

You can use the SET NODE command to specify default privileged and 
nonprivileged access control strings for outbound logical link requests. 

Use the SET OBJECT command to specify privileges required to access 
certain objects during inbound logical link requests. You can also use the 
SET OBJECT command to specify a default access control string. For NCP 
commands to be executed at remote nodes, you can either supply explicit 
access control information in the node specification, as parameters in the 
command, or by default. 


3.13.2.1 Establishing Default Privileged and Nonprivileged Accounts 

Use the SET NODE command to specify default access control information for 
connecting to remote nodes. If you have not specified explicit access control 
information in an outbound logical link request, this default information 
is sent with the request. For example, the command below specifies both 
privileged and nonprivileged user names and passwords for node DENVER: 

NCP>SET NODE DENVER- 

_ NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV- 
_ PRIVILEGED USER NETPRIV PASSWORD PRIV 

You should specify default information for all remote nodes with which you 
want to have the option of using default access control. 


3.13.2.2 Specifying Privileges for Objects 

Use the SET OBJECT command with the PRIVILEGE parameter to specify 
those privileges that will cause the privileged user account to be used rather 
than the nonprivileged user account. The privilege list accompanying the 
parameter specifies those privileges required for all inbound connections to 
that object. For example, you may want to make the FAL object accessible 
to any network user, whereas you want to control access to the NML object. 
The following command specifies privileges for the NML object in this 
instance: 

NCP>SET OBJECT NML PRIVILEGES OPER 

You need not specify privileges for FAL because it requires only NETMBX 
and TMPMBX privileges. 


3.13.2.3 Setting Default Inbound Access Control Information 

Use the SET OBJECT command with the USER, ACCOUNT, and 
PASSWORD parameters to specify default inbound access control 
information. For example, the following command specifies default 
information that the local DECnet-VAX node can use for inbound connects 
from SLD: 

NCP>SET OBJECT HLD USER NETNONPRIV PASSWORD NONPRIV 
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3.13.2.4 Indicating Access Controls for Remote Command Execution 

Access control is used for remote NCP command execution. When you issue 
the SET EXECUTOR NODE and TELL commands, you can explicitly specify 
access control information, or you can default to information contained in the 
configuration database. 

Two formats exist to supply access control information explicitly for these 
commands. You can use either a standard VAX/VMS node specification 
(node"user password account"::) or the NCP parameters USER, ACCOUNT, 
or PASSWORD. For example, the following commands perform the same 
operation: 

NCP>SET EXECUTOR NODE TRNTO"GRAY MARY":: 

NCP>SET EXECUTOR NODE TRNTO USER GRAY PASSWORD MARY 

The same formats exist for the TELL command. Use of the standard 
VAX/VMS node specification format allows you to use a logical name as 
the node-id for these commands. It is possible to override access control in a 
logical name with explicit access control information in the command. 

You can also use access control information to cause NML to run under an 
account other than the default DECnet privileged account on the local node. 
Issue the following command for this purpose: 

NCP>SET EXECUTOR NODE TRNTO»user-id password" 


3.13.3 Node-Level Access Control Commands 

At the node level, you can specify access control commands that determine 
what connections can be made. If your node expects to receive dialup 
dynamic asynchronous connection requests, you can check the type of the 
dialup node before permitting the connection. 

The NCP commands SET NODE ACCESS and SET EXECUTOR DEFAULT 
ACCESS, when used together, allow you to partition your network to allow 
specific access for each node. For example, assume that there are 10 nodes 
in your network, named A through J. The executor is node A. Because 
most network traffic occurs between nodes A, B, and C, you could use the 
following commands to allow unrestricted incoming and outgoing logical link 
connections among those nodes: 

NCP>SET NODE A ACCESS BOTH 
NCP>SET NODE B ACCESS BOTH 
NCP>SET NODE C ACCESS BOTH 

Next, assume that you want to allow local users to initiate connections to 
node D, but restrict connections from that node. Issue the command 

NCP>SET NODE D ACCESS OUTGOING 

Finally, assume that you want to allow incoming logical link connections from 
all other remote nodes (E through J), but restrict outgoing connections from 
the executor node. Issue the command 

NCP>SET EXECUTOR DEFAULT ACCESS INCOMING 

It is important to stress that the executor will check for a node ACCESS entry 
before it checks for the DEFAULT ACCESS entry. You should also remember 
that if the executor's state is set to OFF or SHUT, no logical links will be 
allowed. 
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You can indicate the type of node that can connect to your node over a point- 
to-point circuit by specifying the INBOUND parameter in the SET NODE 
command. The INBOUND parameter permits you to check the type of a 
connecting node before you form a dynamic connection with the node. For 
example, if you expect the Micro VMS node MYNODE to initiate a dynamic 
connection by dialing in over a specific terminal line, you can specify the 
following in your node database: 

NCP>SET NODE MYNODE INBOUND ENDNODE 

If the node MYNODE dials in as a router, rather than as an end node, the 
dynamic connection is not formed. If you specify INBOUND ROUTER for 
the node and it dials in as an end node, the dynamic connection is permitted. 

Note that when the node parameter INBOUND is specified, the circuit 
parameter VERIFICATION INBOUND must also be set for the circuit over 
which the connection is to be made (see Section 3.13.1). If VERIFICATION 
INBOUND is not set for the circuit, the node parameter INBOUND is ignored. 


3.13.4 Proxy Login Access Control Commands 

Access to individual accounts on the local node by proxy login is enabled by 
the DEFAULT PROXY setting in the executor database. The default setting of 
DEFAULT PROXY for each node permits both incoming and outgoing proxy 
access. This setting is the recommended option. You can, however, use the 
SET EXECUTOR command to modify the DEFAULT PROXY value at the 
local node. 

The default value of the DEFAULT PROXY entry in the executor database is 
equivalent to issuing the following command: 

NCP>SET EXECUTOR DEFAULT PROXY BOTH 

The system manager has the option of changing the default value, as in the 
following command, which prohibits any proxy login to or from the local 
node. 

NCP>SET EXECUTOR DEFAULT PROXY NONE 

To display the value of the DEFAULT PROXY entry for your node, use the 
command 

NCP>SHOW EXECUTOR CHARACTERISTICS 

If proxy login access is enabled at your node, the resultant display is 

Default proxy access = incoming and outgoing 

When proxy login access is enabled, the remote user can access a file 
accessible to the local account to which he has proxy access by using the 
node specification NODE:: in the standard VAX/VMS file specification. For 
example, a remote user can specify the following form of file specification to 
access a file on an account on node TRNTO to which he has proxy access: 

TRNTO::filename 

To override proxy login, the remote user with a proxy account on a node can 
specify NODE"":: in the file specification, causing the default nonprivileged 
DECnet account to be used, since explicit access control will be passed to the 
remote node. 
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Access to a network object through a proxy account is controlled by the 
PROXY parameter in the object database. By default, DECnet-VAX has set in 
the configuration database PROXY values for some network objects. These 
default values are the recommended values. To specify or modify the PROXY 
parameter for an object, use the SET or DEFINE OBJECT command with 
the PROXY parameter. In the following example, the outgoing proxy access 
option is set for the object MAIL. 

NCP>SET OBJECT MAIL PROXY OUTGOING 

To display the setting for the PROXY parameter in the database, use the 
SHOW OBJECT command with the CHARACTERISTICS parameter, as in the 
following command: 

NCP>SHOW KNOWN OBJECT CHARACTERISTICS 


The resulting display lists the database entries for each known object, 
indicating any proxy access that is enabled for the object. For object MAIL, 
the display is shown below. 


OBJECT = MAIL 
Number 
User id 
Password 
Proxy access 


= 27 

= NETNONPRIV 
= TREWQ 
= outgoing 


3.14 Monitoring the Network 

You can monitor network activity in one of two ways: by using the NCP 
command SHOW or by using the event logging facility and the SET 
LOGGING command. This section discusses the use of the SHOW and 
LIST commands. Refer to Section 2.9 for a discussion of events and event 
logging, and Section 3.12 for a description of the SET LOGGING command. 

NCP provides commands to display information about network components, 
regardless of whether they are defined in the volatile or permanent database. 
The NCP command SHOW displays information about components for the 
running network. The NCP command LIST performs a similar function, 
except that it lets you display and verify information in the permanent 
database. In many cases, this information will be a subset of the information 
displayed for the volatile database. 

In general, the SHOW command allows you to monitor the operation of the 
running network. For example, whenever someone changes the state of a 
circuit, the configuration of the running network, in terms of reachable and 
unreachable nodes, may be changed as well. A circuit failure could have the 
same effect. NCP allows you to display the status of network circuits, lines, 
modules, and nodes, and thereby to detect such conditions. 

When you issue the SHOW and LIST commands, NCP allows you to select 
components and display types. You can choose among several display 
types, depending on the information you want. The display type determines 
the format and type of information that NCP displays. Display types are 
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described below. 
CHARACTERISTICS 


STATUS 


SUMMARY 


EVENTS 


COUNTERS 


Includes static information that is usually specified in the 
configuration database. Depending on the component, 
this information may include the identification of a local 
node and relevant routing parameters, the names 
and numbers of known network objects, and the 
identification and cost of circuits connected to the 
local node. For VAX PSI, the information may include 
identification of a local DTE and relevant parameters; 
packet size, window size, and other network parameter 
values; device identification; and timer values. 

Includes dynamic information that usually reflects 
network operations for the running network. Depending 
on the component, this information may include the 
local node and its operational state, reachable and 
unreachable nodes and their operational states, and 
circuits with their operational states. For VAX PSI, the 
information reflects the operation of the running VAX 
PSI software. Depending on the component, this may 
include identification of the line with its operational state. 

Includes only the most useful information derived from 
both static and dynamic sources. This information 
is usually an abbreviated list of information provided 
for both the CHARACTERISTICS and STATUS display 
types. For VAX PSI, it is usually an abbreviated list of 
information provided for the STATUS display type. 

Includes information about events currently being 
logged for the logging component. This display type 
is valid only for the SHOW LOGGING and LIST LOGGING 
commands. 

Provides counter information for circuits, lines, modules, 
and nodes, including the local node. Counters are 
discussed in the sections of this chapter that describe 
the circuit, line, module, and node commands. 


If you do not specify a display type when issuing a SHOW or LIST command, 
SUMMARY is the default. Examples of these display types and their formats 
are given in the VAX/VMS Network Control Program Reference Manual. 

When you display information about network components, you can use either 
the singular or plural form of the component, as shown in the following 
example: 

NCP>SHOW NODE BOSTON CHARACTERISTICS 


NCP>SH0W KNOWN NODES CHARACTERISTICS 


For several components, there is a second form of the plural. This form 
is the word ACTIVE. Whereas the word KNOWN displays information 
for components available to the local node, the word ACTIVE displays 
information for all active components—that is, components whose state is 
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other than OFF. Use the word ACTIVE with circuit, line, node, and logging 
components. For example, the following command displays the characteristics 
for all active nodes in the network: 

NCP>SHOW ACTIVE NODES CHARACTERISTICS 


The word ADJACENT is also used as a plural in the SHOW NODE command, 
as in the following 

NCP>SHOW ADJACENT NODES STATUS 

All NCP display commands optionally allow you to direct the information 
displayed to a user-specified output file. For example: 

NCP>SH0W KNOWN LOGGING SUMMARY TO SYS$MANAGER:NET.LOG 

This command creates the file SYS$MANAGER:NET.LOG containing 
summary information of all known logging for the running network. The 
default file type is LIS. If the specified file already exists, NCP appends 
the display information to that file. If you do not specify an output file, 
SYS$OUTPUT is the default. 

NML must have the BYPASS privilege to display passwords for the SHOW or 
LIST commands; if it does not, no information will appear if you use SHOW, 
and the "no access rights" message will appear if you use LIST. 
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DECnet-VAX can act as the host node in performing the following services 

for unattended systems: 

• Downline loading of an unattended system: transferring a copy of an 
operating system file image from a VAX/VMS node to a target node. 

• Upline dump of memory from an unattended system: transferring a copy 
of a memory image from an unattended target node to your VAX/VMS 
node. 

• Downline loading of an RSX-11S task from a VAX/VMS node. 

• Connecting to a remote console: permitting a VAX/VMS terminal to act as 
the console for certain unattended systems, such as the DIGITAL Ethernet 
Communications Server running Router Server Software. 

These operations are described in this chapter. Note that host services are not 

available over asynchronous lines. 


4.1 Loading Unattended Systems Downline 

DECnet-VAX allows you to load an unattended system downline. Downline 
loading involves transferring a copy of the file image of a remote node's 
operating system from a VAX/VMS node to the unattended target node. For 
example, DECnet-VAX permits you to load an RSX-11S operating system 
file image from your VAX/VMS node downline to a target node. Downline 
loading can be initiated by a VAX/VMS operator or by the target node. Both 
procedures are discussed in this section. 

To understand downline loading, it helps to distinguish the nodes involved 
in the loading sequence. In the node descriptions below, the command node 
and the executor node can be the same or different nodes, but cannot be the 
target node. 

• Command node. An operator-initiated downline load request originates 
at the command node. You use either the NCP command LOAD or 
TRIGGER to initiate this request. 

• Executor node. The executor node actually performs a downline load or 
trigger operation. It must be adjacent to the target node because it uses 
circuit-level access. 

• Target node. The target node receives the bootstrap loaders and the 
system image file. 
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4.1.1 Downline System Load Operation 

Downline loading is initiated in one of two ways: either an operator initiates 
the operation with the NCP command LOAD or TRIGGER, or the target 
node initiates the operation by triggering its bootstrap ROM and sending 
a program load request to the executor node. With an operator-initiated 
load, the executor starts the operation by sending either a trigger message (if 
necessary) or a load file to the target node. Essentially, the trigger message 
provides the restart capability for an unattended target node. Once the target 
node is triggered, it will then load itself in whatever manner its primary 
loader is programmed to operate. This could include requesting a downline 
load from either the executor that just triggered it or another adjacent node; 
the target node could also load itself from its own mass storage device. 

DECnet uses the maintenance operation protocol (MOP) to perform a 
downline load operation. MOP is the protocol used by the network 
management portion of DNA to perform maintenance functions such as 
circuit testing, triggering, upline dumping, and downline loading. Once 
triggered, the target node usually sends MOP program request messages 
requesting a program to be loaded. 

If the load is target initiated, DECnet-VAX detects MOP messages coming 
over the circuit and sets the circuit's state to AUTOSERVICE. NML uses the 
MOM subprocess named MOM_circuit-id_process-number (for example, 
MOM_UNA-O_l) to perform the load. NML, through that subprocess, 
searches the volatile database for a node entry with a service circuit that 
matches the circuit over which the message was received, and, if it is an 
Ethernet circuit, an Ethernet address that matches the Ethernet source 
address from which the message was received. NML then performs the 
load operation. In this manner, NML provides the control mechanism for the 
loading process. Figure 4-1 illustrates this loading process. 

If the target on an Ethernet circuit does not have a specific node from which 
to request a program load (for example, if the target's loading node crashes, 
or if the load is initiated by means of the BOOT button on the target), the 
target proceeds as follows: 

1 The target node sends a program load request message to the Ethernet 
load assistance multicast address AB-00-00-01-00-00 (described in 
Section 3.3.4.4). This message is a request for any node on that Ethernet 
to perform the load. 

2 The nodes on the Ethernet whose circuits are enabled to perform service 
functions check their own databases for a remote node entry whose 
Ethernet hardware address matches that of the target node to determine 
if they can load the target downline. If so, they send to the target the 
secondary loader (if the target is requesting the secondary loader), or a 
message volunteering to do the load (if the target is requesting the tertiary 
loader or operating system). 

3 The target choses the node responding first to continue the loading 
sequence. It does not send a message to any other node. The loading 
sequence continues normally from there. 

Conversely, an operator-initiated load using NCP directly requests NML to 
perform the load operation. The target node's primary bootstrap may or may 
not have to be triggered depending on the state of the target. The target node 
is triggered primarily to put it into a known state and to force it to supply 
program request information. Figure 4-2 illustrates the loading process. 
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Figure 4-1 Target-Initiated Downline Load 


BOSTON 

(EXECUTOR NODE) 



NYC 

(TARGET NODE) 

ZK-550-81 


Use the NCP command LOAD or TRIGGER to perform an operator-initiated 
downline load. The TRIGGER command allows you to directly trigger the 
remote node's bootstrap ROM, which causes the target node to send its host 
a request for a load operation. The programs to be loaded may come from a 
local disk file on the target node, another adjacent node, or the executor node. 

Note that the TRIGGER command may or may not initiate a downline load. 
One of the functions of this command is to simulate the operation that occurs 
when the BOOT button on the target node is pushed. A bootstrap operation 
from the local disk may result. 

When you use the LOAD command, the executor node proceeds with the 
load operation according to the options specified in the initial load request. 
Any required information that has been defaulted is obtained from the volatile 
database. With this information, the executor is thereby able to control the 
load sequence. 

Section 4.1.2 describes the TRIGGER and LOAD commands, their parameters, 
and examples of their use. 
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Figure 4-2 Operator-Initiated Downline Load 
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4.1.1.1 Load Sequence 

The load sequence is the same, regardless of whether the request was initiated 
by the operator or the target node. The first program to run at the target node 
is the primary loader. Typically, this program is either executed directly 
from the target node's bootstrap ROM, or it is in the microcode of the load 
device (DMC, DMR, DMP, DMV, UNA, or QNA). Once the target node's 
primary loader is triggered, the target node sends a message to the executor 
node requesting a program load. This program may come directly from the 
executor or from a remote node. Usually, the primary loader requests a 
secondary loader program, which, in turn, may request a tertiary loader. The 
final program to be loaded is the operating system. In this sequence, each 
program requests the next one until the operating system is loaded. 
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The secondary loader is small and is always sent as a single message. The 
tertiary loader and the operating system are larger and are sent in segments. 
For both of these latter two, the last segment is followed by a "PARAMETER 
LOAD WITH TRANSFER ADDRESS" message, which supplies the start 
address of the image just loaded and contains extra values for the node 
identification and the host identification. 


4.1.1.2 Load Requirements 

Prior to attempting a downline load operation, you must ensure that nodes, 

lines, and circuits meet the following requirements: 

• The target node must be connected directly to the executor node. The 
executor node provides the line- and circuit-level access. 

• The primary loader must either be a cooperating program in the target 
or in the microcode of the target's device (DMC, DMR, DMP, DMV, or 
UNA). The downline load operation usually involves loading a series of 
bootstraps, each of which requests the next program until the operating 
system itself is loaded. 

• The executor must have access to the load files. The location of the files 
can be either specified in the load request or defaulted to in the volatile 
database. Remote files are obtained through remote file access operations. 
(Refer to the examples in Section 4.1.2.4.) 

• The target node must be able to recognize the trigger operation or must be 
triggered manually. 

• The circuit involved in the load operation must be enabled to perform 
service functions. It must also be in the ON or SERVICE state; a 
multiaccess Ethernet circuit must be in the ON state. For example, the 
following command readies circuit DMC-0 for downline loading node 
BANGOR in our network example: 

NCP>SET CIRCUIT DMC-0 SERVICE ENABLED STATE ON 

• You must turn the line to ON and specify a service timer for the line. This 
timer sets the MOP timeout constant for retransmission if necessary. This 
is the method by which MOP handles error recovery. The default for the 
service timer is 4000 milliseconds. In the example below, the command 
sets the retransmission frequency to 5000 milliseconds and turns on line 
DMC-0. 

NCP>SET LINE DMC-0 SERVICE TIMER 5000 STATE ON 

Refer to the Maintenance Operation Protocol Functional Specification for a 

complete description of MOP error recovery. 


4.1.2 Operator-Initiated Downline Load Parameters 

The most convenient method of downline loading involves setting default 
information in the volatile database. The operator can use the NCP command 
SET NODE to establish default information for the target node in the 
volatile database. These default parameters are also used for target-initiated 
downline loads, though the MOP program load message can override some 
of the defaults. (This default method is discussed later in this chapter.) 
Alternatively, you can override the default by specifying several parameters 
for the NCP commands TRIGGER or LOAD. This section describes each 
parameter and illustrates its use. 
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4.1.2.1 TRIGGER Command 

The TRIGGER command triggers the bootstrap mechanism of a target node, 
which causes the node to request a downline load. Because the system that is 
being booted is not necessarily a fully functional network node, the operation 
must be performed over a specific circuit. To bring up the system at the target 
node, use either the TRIGGER NODE or TRIGGER VIA command. If you 
use the TRIGGER NODE command and do not specify a loading circuit, the 
executor node obtains the circuit identification associated with the target node 
from its volatile database. If you use the TRIGGER VIA command, which 
indicates the loading circuit but not the node identification, the executor node 
uses the default target node identification in its volatile database. To identify 
the target node in the volatile database, specify the SET NODE command 
with the appropriate SERVICE CIRCUIT parameter, which establishes the 
circuit to be used for loading. 

The command below triggers node BANGOR in the network example. 

NCP>TRIGGER NODE BANGOR VIA DMC-0 

Note that this command specifies a DDCMP circuit over which the operation 
is to take place. Figure 4-3 also illustrates the use of the TRIGGER command 
for downline loading over a DDCMP circuit in the network example. 

If downline loading is to occur over an Ethernet circuit, the executor node 
uses the Ethernet physical address of the target node to distinguish it from 
other adjacent nodes on the same Ethernet circuit. The PHYSICAL ADDRESS 
parameter for the target node is required in the TRIGGER VIA command and 
optional in the TRIGGER NODE command. 

If you do not specify an Ethernet physical address in the TRIGGER NODE 
command, DECnet-VAX derives one from the target's node number and 
attempts to trigger the node. A target node that is running DECnet software 
has set its own Ethernet physical address and recognizes the address; 
otherwise, the target node recognizes only the Ethernet hardware address 
set by the manufacturer. If unsuccessful in triggering the node, DECnet- 
VAX attempts to use the Ethernet hardware address of the target node from 
the volatile database to trigger it. You can set in the volatile database the 
Ethernet hardware address originally assigned to the target node's DEUNA 
or DEQNA controller by specifying the HARDWARE ADDRESS parameter in 
the SET NODE command. (Refer to Section 3.3.4 for a description of Ethernet 
addressing.) 

Figure 4-4 illustrates the use of the TRIGGER NODE command for downline 
loading a target node over Ethernet circuit UNA-0. 

When you use the TRIGGER command, it may not always be obvious how 
the system load is performed. Essentially, this command provides the trigger 
message that controls the restart capability for an unattended target node. 
Once the target node is triggered, it will then load itself in whatever manner 
its primary loader is programmed to operate. The target node could request 
a downline load from either the executor that just triggered it or another 
adjacent node, or the target node could load itself from its own mass storage 
device. 

One parameter that you can specify for the TRIGGER command is SERVICE 
PASSWORD. This parameter supplies a boot password, which may be 
required by the target node (see Section 4.1.2.9). If you do not specify this 
parameter, a default value from the volatile database is used. Use the SET 
NODE command to establish a default value for this parameter in the volatile 
database. If no value is set in the volatile database, the value is 0. 
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Figure 4—3 Operator-Initiated Downline Load over DDCMP 
Circuit (TRIGGER Command) 


BANGOR 

(Target Node) 


DENVER 



BOSTON 

(Executor Node) 


NYC 


NCP Commands: 

NCP>SET EXECUTOR NODE BOSTON 
NCP>SET LINE DMC-1 STATE ON 
NCP>SET CIRCUIT DMC-1 STATE ON 

NCP>TRIGGER NODE BANGOR SERVICE PASSWORD FEFEFEFE 

/K 1887 84 



4.1.2.2 LOAD Command 

Use the LOAD NODE and LOAD VIA commands to load software downline 
to a target node. For example, the following command loads node BANGOR: 

NCP>LOAD NODE BANGOR 
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Figure 4—4 Operator-Initiated Downline Load over Ethernet 
Circuit (TRIGGER Command) 


UNA-0 



BOSTON TARGET 

(EXECUTOR NODE) (TARGET NODE) 


NCP Commands: 

NCP>SET LINE UNA-0 STATE ON 
NCP>SET CIRCUIT UNA-0 STATE ON 

NCP>TRIGGER NODE TARGET PHYSICAL ADDRESS AA-00-04-00-CB-04 VIA UNA-0 

ZK-1213-82 


The LOAD NODE command requires the identification of the service circuit 
over which to perform the load operation. If you do not explicitly specify 
a service circuit in this command, the executor node uses the SERVICE 
CIRCUIT from the volatile database entry for the target node. You must use 
the SET NODE command to include the SERVICE CIRCUIT entry in the 
volatile database. Alternatively, you can explicitly include the circuit in the 
command LOAD NODE BANGOR VIA DMC-0. 

You could also use the LOAD VIA command to specify the circuit over 
which to perform a downline load. For example, to load using circuit DMC-0 
connected to the executor node, issue the command 

NCP>L0AD VIA DMC-0 

The executor node obtains the rest of the necessary information from its 
volatile database. The LOAD NODE and LOAD VIA commands will work 
only if the target node can be triggered by the executor or if the target has 
been triggered locally. 

If the loading circuit is a multiaccess Ethernet circuit, the executor node uses 
the Ethernet physical address of the target node to differentiate the node 
from other adjacent nodes on the same Ethernet. The PHYSICAL ADDRESS 
parameter must be specified in the LOAD VIA command (which does not 
identify the target node) and can optionally be specified in the LOAD NODE 
command. 

If you do not specify the PHYSICAL ADDRESS parameter in the LOAD 
NODE command, DECnet-VAX derives the Ethernet physical address from 
the target node number and attempts to load the target node. A target node 
that is running DECnet software has set its own Ethernet physical address 
and will recognize this address; otherwise, the target node will recognize 
only the Ethernet hardware address set by the manufacturer. If unsuccessful 
in loading the node, the executor node will attempt the load using the 
Ethernet hardware address of the target node from the volatile database. 
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You can set in the volatile database the Ethernet hardware address originally 
assigned to the target node's DEUNA or DEQNA controller, by specifying the 
HARDWARE ADDRESS parameter in the SET NODE command. (Refer to 
Section 3.3.4 for a description of Ethernet addressing.) 

Figure 4-5 illustrates the use of the LOAD command for downline loading 
over Ethernet circuit UNA-0. 

Figure 4-5 Operator-Initiated Downline Load over Ethernet 
Circuit (LOAD Command) 


UNA-0 


r-1 



BOSTON TARGET 

(EXECUTOR NODE) (TARGET NODE) 


NCP Commands: 

NCP>SET NODE TARGET SERVICE CIRCUIT UNA-0 
NCP>SET LINE UNA-0 STATE ON 
NCP>SET CIRCUIT UNA-0 STATE ON 

NCP>LOAD NODE TARGET PHYSICAL ADDRESS AA-00-04-00-CB-04 


ZK-1214-82 


If you choose to override the default parameters for the LOAD commands, 
you can control the following aspects of the load sequence: 

• The host node that the target node is to use once the target comes up 

HOST node-id 

• The identification of the load file 

FROM file-id 

• The identification of the loader programs 

SECONDARY LOADER file-id 
TERTIARY LOADER file-id 

• The software type to be loaded downline first 

SOFTWARE TYPE software-type 

The software-type can be any of the following: 

SECONDARY LOADER 
TERTIARY LOADER 
SYSTEM 
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If the software-type is not specified in the first MOP program request, 
the NCP command, or the volatile database, the default is SECONDARY 
LOADER. 

• The identification of the CPU type and the corresponding software 
identification 

CPU cpu-type 

SOFTWARE IDENTIFICATION software-id 

• The identification of the target node's line device type that is to handle 
service operations 

SERVICE DEVICE device-type 

• The identification of the service password for triggering the target node's 
bootstrap mechanism 

SERVICE PASSWORD hex-password 

When issuing the LOAD NODE and LOAD VIA commands, you can specify 
any or all of the parameters listed above. Any parameter not specified in 
the command defaults to whatever information is specified in the volatile 
database. Use the SET NODE command to establish default information for 
the target node's parameters in the volatile database. 


4.1.2.3 Host Identification 

At the end of the load sequence, the target receives a message with the name 
of the host and places that name in its volatile database. The target can then 
use the HOST node-id for downline task loading applications. The host may 
be the executor node or any other reachable node except for the target itself. 
Use the SET NODE command to specify a default host node where the target 
will find the files used to load tasks downline. For example, the command 
below sets the host to node NYC once node BANGOR comes up as a network 
node (if BANGOR has the necessary DECnet software): 

NCP>SET NODE BANGOR HOST NYC 

If the host is unspecified, the executor serves as the default host. You can 
override any default information by using the HOST parameter for the LOAD 
command. 


4.1.2.4 Load File Identification 

The load files are those files to be loaded downline to the target node. 

These files may consist of a secondary loader, a tertiary loader, and an 
operating system image. You can specify default load file names in the 
volatile database with the SET NODE command. Load files default to 
SYS$SYSTEM:filename.SYS. If the files are on another node, specify node-id:: 
at the beginning of the file specification. 

Figure 4-6 illustrates the use of the LOAD NODE command for loading a 
target node over a DDCMP circuit. 

If the secondary and tertiary file names are not included in the LOAD 
command or as entries in the volatile database for the target node, the load 
files are selected according to the service device type on the target system, not 
by the device type on the executor. The default secondary and tertiary loader 
files are as listed in Table 4-1. The DECnet-llS kit includes the files listed in 
Table 4-1. 
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Figure 4-6 Operator-Initiated Downline Load over DDCMP 
Circuit (LOAD Command) 


BANGOR 

(Target Node) 



NYC 


NCP Commands: 


NCP>SET EXECUTOR NODE BOSTON 
NCP>SET LINE DMC-1 STATE ON 
NCP>SET CIRCUIT DMC-1 STATE ON 

NCP> LOAD NODE BANGOR FROM NYC::SYS$SYSTEM:RSX11 S.SYS 

ZK 1868-84 


If load file names are not specified in the target's load request, the NCP 
command LOAD or the volatile database, NML will provide them by 
concatenating the service device with the prefix SEC or TER. For example, 
if the service device is a DMC, NML uses the file names SECDMC.SYS and 
TERDMC.SYS. 
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Table 4-1 Default Loader Files by Target Device Type 


Device Type 

Secondary Loader 

Tertiary Loader 

DP11 

SECDP.SYS 

TERDP.SYS 

DL1 1 

SECDL.SYS 

TERDL.SYS 

DU 1 1 

SECDU.SYS 

TERDU.SYS 

DQ1 1 

SECDQ.SYS 

TERDQ.SYS 

DUP1 1 

SECDUP.SYS 

TERDUP.SYS 

DMC1 1 

SECDMC.SYS 

TERDMC.SYS 

DUV11 

SECDUV.SYS 

TERDUV.SYS 

DPV 

SECDPV.SYS 

TERDPV.SYS 

DA 

SECDA.SYS 

TERDA.SYS 

DMP 

SECDMP.SYS 

TERDMP.SYS 

DMV1 1 

SECDMV.SYS 

TERDMV.SYS 

QNA 

SECQNA.SYS 

TERQNA.SYS 

UNA 

SECUNA.SYS 

TERUNA.SYS 


If, however, you include the secondary and tertiary file names as entries in 
the volatile database for the target node, they can override the default loader 
files described above. By using the SET NODE command, you can select your 
own special load files for a particular target node. If you do not specify the 
load files, you can change the service device type at the target node without 
changing the target node's database entry at the executor node. 

The system image file entry in the host node's volatile database serves as the 
default file name for the operating system to be downline loaded. This file 
name is required when the target node is to be loaded, but it can be supplied 
by the LOAD command. 


4.1.2.5 Software Type 

Along with identifying load files, you can specify the file types to be used for 
the initial load. For example, if the target node is already running a secondary 
loader program, you may only want to load the tertiary loader and operating 
system downline. To do this, you use the SOFTWARE TYPE parameter with 
the LOAD command. For example, to load a tertiary loader file, which in turn 
would load the operating system image, you would use the command below. 

NCP>LOAD NODE BANGOR SOFTWARE TYPE TERTIARY LOADER 

Use the SET NODE command to specify default software type information for 
the target node entry in the volatile database. If no software type information 
is specified in the volatile database, the default type is the secondary loader. 


4.1.2.6 CPU and Software Identification 

The software identification is the default program name of the operating 
system to be loaded downline. Use the SOFTWARE IDENTIFICATION 
parameter to specify a software-id of up to 16 alphanumeric characters. For 
example, in the following command the CPU parameter specifies the default 
processor type to be loaded downline: 

NCP>SET NODE BANGOR SOFTWARE IDENTIFICATION RSX_11S_V3.2 
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4.1.2.7 Service Device Identification 

The service device is the controller on the target node end of a service circuit. 
The service device handles downline loading in a variety of ways, depending 
on the device used. In particular, this device influences the type of files 
suitable for downline loading. Default load file names are selected according 
to the service device for the target node. 

The SERVICE DEVICE parameter identifies the default secondary and tertiary 
loaders for the load operation. This parameter is required for any downline 
load if the secondary and tertiary load files are not specified in the volatile 
database of the target node. SERVICE DEVICE is also required if the program 
load requests from the target node do not specify the secondary and tertiary 
load file names. Use the SET NODE command to specify the service device 
type in the volatile database. For example, the command below identifies the 
service device as a DMC device controller. 

NCP>SET NODE BANGOR SERVICE DEVICE DMC 

By using the SERVICE DEVICE parameter for the LOAD command, you can 
override the service device default information. 


4.1.2.8 Service Circuit Identification 

In terms of the executor, the service circuit is a circuit connecting the executor 
node with an adjacent target node. When you issue the LOAD and TRIGGER 
commands, you must specify or default to a circuit over which the load 
operation is to take place. Use the VIA parameter to explicitly identify the 
circuit when issuing these commands. If specifying an Ethernet circuit in the 
LOAD VIA command, you must include the PHYSICAL ADDRESS parameter 
in the command. 

If you do not specify a circuit, this information defaults to the circuit specified 
in the target node's volatile database. To set a service circuit in the volatile 
database, use the SET NODE command. 


4.1.2.9 Service Passwords 

When defining nodes for downline loading in the local volatile database, the 
system manager can specify a default service password. This password may 
be required to trigger the primary bootstrap mechanism on the target node. 

If a user issues a LOAD or TRIGGER command without a service password, 
then this default parameter will be used if the target node requires one. To 
set a service password in the volatile database, use the SET NODE command. 
This password must be a hexadecimal number in the following ranges: 

• For DMC/DMR/DMP/DMV, the range is 0 to FFFFFFFF 

• For UNA/QNA, the range is 0 to FFFFFFFFFFFFFFFF 

For example, to load node BANGOR on circuit DMC-1: 

NCP>SET NODE BANGOR SERVICE PASSWORD FEFEFEFE 
NCP>LOAD NODE BANGOR 


4.1.2.10 Diagnostic File 

Once the target node is loaded downline, it can request diagnostics. Use the 
DIAGNOSTIC FILE parameter in the SET NODE command to identify in the 
volatile database the diagnostics file that the target node can read. 
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4.2 Dumping Memory Upline from an Unattended System 

As a DECnet-VAX system manager, you can include certain SET NODE 
parameters in the volatile database that will allow an adjacent unattended 
node to dump its memory into a file on your VAX/VMS system. This 
procedure is referred to as upline dumping. It is a valuable tool for crash 
analysis; that is, programmers can analyze the dump file and determine why 
the unattended system failed. When an unattended system that selected the 
appropriate support at system generation detects an impending system failure, 
that system will request an upline dump; for example, an RSX-11S system 
may request an upline memory dump to a VAX/VMS system. 

For upline dump operations, the local VAX/VMS node is referred to as the 
executor and the adjacent unattended node as the slave. 


4.2.1 Upline Dump Procedures 

This section describes the procedures for an upline dump initiated by a 
slave node. DECnet uses the maintenance operation protocol (MOP) to 
perform an upline dump operation. MOP is a subset of the DIGITAL Data 
Communications Message Protocol (DDCMP) that sends messages used for 
circuit testing, triggering, downline loading, and upline dumping. Refer to the 
Maintenance Operation Protocol Functional Specification for a more complete 
discussion. 

There are four steps involved in the upline dump process. The actual dump 
takes place by repeating step 3. 

1 When a slave node senses a system failure, it sends a memory dump 
request to the VAX/VMS host node, or, on Ethernet, to a dump assistance 
multicast address if an Ethernet host is not available (see below). The 
request is a MOP request dump service message. This message might 
contain information about the slave's memory size (DUMP COUNT) and 
the upline dump device type at the slave. 

2 If the message from the slave includes a DUMP COUNT value, the host 
node uses it. Otherwise, the host node checks the slave node's entry in its 
volatile database for the DUMP COUNT, the target address from which 
to start dumping (DUMP ADDRESS) and the file where the memory 
will be stored (DUMP FILE) for the slave. (If no entry exists for DUMP 
ADDRESS, the value defaults to 0.) The host node, which can now be 
considered the executor, sends a MOP request memory dump message to 
the slave with the starting address and buffer size values. 

3 Using the values it received from the executor, the slave returns the 
requested block of memory in a MOP memory dump data message. The 
executor receives the block of dump data, places it in the DUMP FILE, 
increments the DUMP ADDRESS by the number of locations sent, and 
sends another request memory dump message to the slave. This sequence 
is repeated until the amount of memory dumped matches the DUMP 
COUNT value. The executor then sends a MOP Dump Complete message 
to the target. 

4 Once the upline dump is completed, the executor node automatically 
attempts to downline load the slave system. It initiates the downline load 
by sending a TRIGGER message to the slave (see Section 4.1). 

Figure 4-7 illustrates the upline dump procedure. 
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Figure 4-7 Upline Dumping of RSX-11S Memory 
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If the target node is on an Ethernet circuit, the target will attempt to perform 
an upline dump to the node that originally loaded it downline. If that node is 
not available, the target node proceeds as follows: 

1 The target node sends a memory dump request to the Ethernet dump 
assistance multicast address AB-00-00-01-00-00 (described in Section 

3.3.4.4). This message is a request for any node on the Ethernet to receive 
an upline memory dump. 

2 The nodes on the Ethernet whose circuits are enabled to perform service 
functions check their own databases to determine if they can accept an 
upline dump. If so, they respond to the target node. The target choses the 
node responding first to continue the dumping sequence. The target does 
not send a message to any other node. The loading sequence continues 
normally from there. Note, however, that you may have to look for event 
0.3 in the event logs for all nodes on the Ethernet to determine which 
node received the dump. See the VAX/VMS Network Control Program 
Reference Manual for a summary of all NCP events. 


4.2.2 Upline Dump Requirements 

Prior to attempting an upline dump operation, you must ensure that the 

nodes, lines, and circuits meet the following requirements: 

• The slave node must be directly connected to the executor node by a 
physical line. The executor node provides the line- and circuit-level 
access. 

• The slave node must be capable of requesting the upline dump when it 
detects a system failure. If the dumping program does not exist on the 
slave, upline dumping cannot occur. 
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• The circuit involved in the dump operation must be enabled to perform 
service functions. It must also be in the ON state. For example, the 
following command readies circuit DMC-0 for upline dumping node 
BANGOR in the network example: 

NCP>SET CIRCUIT DMC-0 SERVICE ENABLED STATE ON 

• If the slave does not supply the DUMP COUNT value, the executor must 
have this value in its volatile database. 

• The executor must have a DUMP FILE entry in the volatile database. If 
the file-id specifies a remote node, the executor transfers the data using 
remote file access routines. 

• Upline dumping cannot occur unless you define a service timer for the 
line. This timer sets the timeout constant for retransmission, enabling 
MOP to handle error recovery. For example, to set the retransmission 
frequency to 5000 milliseconds for line DMC-0, issue the command 

NCP>SET LINE DMC-2 SERVICE TIMER 5000 


4.3 Loading RSX-11S Tasks Downline 

Downline task loading extends nonresident initial task load, checkpointing, 
and overlay support to a DECnet RSX-1 IS node. You can load an RSX-1 IS 
task downline by using the Satellite Loader (SLD) on the DECnet-llS node 
and the host loader (HLD) on the DECnet-VAX node. SLD uses the intertask 
communication facilities of RSX DECnet-llS to communicate with HLD. 
Figure 4-8 illustrates one instance of this relationship. 

By entering RUN TLK at the operator's console of the satellite system, SLD 
requests HLD to load the task downline from a DECnet-VAX node on which 
the file is located. Any request from the satellite or host node could also 
initiate this operation by means of SLD and HLD. 


4.3.1 Setting Up the Satellite System 

You build the SLD task during the RSX-1 IS NETGEN procedure. (Refer 
to the DECnet-RSX Network Generation and Installation Guide.) To allow 
downline task loading, issue the appropriate commands to the RSX-1 IS 
system image. Use VMR to install and fix SLD into the RSX-1 IS system, as 
shown below. 

>VMR 

ENTER FILENAME :RSX1IS 
VMR>INS SLD 
VMR>FIX LDR... 

This sequence of commands establishes SLD as the loading task (LDR...) for 
the executive. 

Note: The information in this section is specific to DECnet-RSX. Refer to the 
related DECnet-RSX documentation. 
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Figure 4-8 Downline Task Loading 


BOSTON Command: 

(HOST NODE) 

VAX/VMS >RUN TLK 

(HLD.DAT file containing HTASK$ TLK) 



NYC 

(SATELLITE NODE) 

RSX-11S 


ZK-553-81 


If the RSX-11S system is to be loaded downline, any tasks to be downline 
loaded to or checkpointed from the RSX-11S system must be installed, but 
not fixed, using VMR. For example: 

>VMR 

ENTER FILENAME :RSX1IS 
VMR>INS TLK 

In this example, entering RUN TLK on a terminal of the RSX-11S remote 
system initiates the downline task load of the file TLK.TSK. 

If the RSX-11S system will not be loaded downline, you must specify the 
node to which SLD will connect, using the VNP command SET EXECUTOR 
HOST (see the DECnet-RSX System Manager's Guide). For example, you could 
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use the command below, where 11 is the number of the node BOSTON on 
which HLD resides: 

>VNP RSX11S 

VNP>SET EXECUTOR HOST 11 


4.3.2 Host Loader Mapping Table 

The Host Loader has a mapping table that is a special user-defined file 
(HLD.DAT) that resides in the SYS$SYSTEM directory. The format of the 
mapping table is as follows: 

HLDTB$ 

HTASK$ TLK,<TRNT0::SYS$DISK:[LOW]TLK>,UNM 
HTASK$ TLK.<SYS$DISK:[LOW.EXT]TLK>,MAP 
HN0DE$ BANGOR 

HTASK$ NCP,<SYS$DISK: [LOW]NCP11S>,LUN 
HTASK$ ...LOA,<SYS$DISK:[TEST]L0A> 

HN0DE$ NYC 

HTASK$ ...MCR,<LB:[RSX1IS.UNMAPPED]BASMCR> 

.END 

The keywords for this table are defined below. 

HLDTBS Defines the file as the HLD mapping table. 

HTASKS Defines a task entry. The arguments for HTASK$ are 

taskname, <file-spec> ,[opt-arg] 

taskname Is the installed task name used to run the task on the 
RSX-1 IS system. 

file-spec Is the task file specification on the host node. You 

must use angle brackets ( <> ) to enclose the file 
specification. 

opt-arg Are optional arguments—MAP^NIVLLUN 

HNODES Defines the exclusive target node upon which the following HTASKS 
can execute. 

This table is almost identical in structure to a MACRO-11 source module used 
by DECnet-RSX to define its downline task loading tables. Note, however, 
that HLD.DAT is accessed directly as a text file and is neither assembled 
nor task built. The organization of the mapping table and special features is 
described below. 

• A task entry contains the name of the installed task, a file specification, 
and an optional control argument. The file specification in the HTASK$ 
macro can omit the file type that defaults to TSK. A node entry contains 
only the node name. 

• Any task entries that precede the first node entry are called general- 
purpose tasks. You can load a general-purpose task into any RSX-1 IS 
node in the network. Task entries that follow a node entry can only be 
sent to that particular node. 

• The same task name can appear more than once in the general-purpose 
task list. This allows both mapped and unmapped RSX-1 IS systems to 
share installed task names. The control argument for a general-purpose 
task is either MAP or UNM. The default is MAP. 
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• Tasks to be loaded downline must be installed in the RSX-11S system, 
which initializes the task's logical unit number (LUN) assignments. LUN- 
fixing is an SLD feature that reinitializes the LUNs after the task has 
been loaded downline. This feature allows a single task to be loaded into 
multiple RSX-11S systems that may have different system-wide device 
assignments. SLD permits you to place a task in a general-purpose task 
list. You can downline load either a general-purpose task or a task after a 
node entry. 

• If you place a task in a general-purpose task list, you can add new nodes 
to the network and can downline load general-purpose tasks to those 
nodes without changing the mapping table. Nodes that are to receive 
only general-purpose tasks need not be mentioned in HLD.DAT. Note, 
however, that general-purpose tasks cannot be checkpointed. 


4.3.3 HLD Operation and Error Reporting 

When SLD attempts to connect to HLD, NETACP on the DECnet-VAX node 
uses the default inbound access control information specified for the HLD 
object by the system manager (see Section 3.13). You must make sure that 
the files associated with the tasks to be loaded or checkpointed are accessible 
from the resulting process created by this connection. 

When the load operation completes, whether successfully or unsuccessfully, 
the log file SYS$LOGIN:NETSERVER.LOG (described in Section 2.6.3) 
contains information describing the operation, the node, and the task. This 
information may consist of an error returned from RMS or certain HLD- 
specific messages that indicate either errors in HLD.DAT or inconsistencies in 
the file to be loaded. Messages associated with these inconsistencies are listed 
below. 


4.3.3.1 HLD Error Messages 

The following is a list of HLD error messages. 

Format error in HLD.DAT 

The format of the HLD mapping table is incorrect. For example, this error 
could occur if HNODE$ was expected but not found in the table. Re-create 
the table with the appropriate format. 

Syntax error in HLD.DAT 

The syntax of an element in the HLD mapping table is incorrect. For example, 
you do not have angle brackets enclosing the file specification. Re-create the 
table. 

Task name not found 

The task to be loaded downline is not specified in the HLD mapping table. 
Re-create the table such that it contains this task name. 

No header in task file 

The file was built with the /-HD switch. Hence it is not a valid RSX-11S task 
image. Rebuild the task. 

Mapped task not on 4K boundary 

The file was not built with the /MM switch. This error is for mapped 
RSX-11S systems only. Rebuild the task. 
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Unmapped partition mismatch 

The TKB address does not correspond with the starting address of the 
partition in the RSX-11S system. This error is for unmapped RSX-11S 
systems only. Rebuild the task with a PAR= statement that specifies the 
correct starting address. 

File too big for partition 

The initial load size of the file is larger than the partition size in the RSX-11S 
system. Either make the partition larger or rebuild the file to use a smaller 
partition size. 

Partition too big for checkpoint space 

The partition size in the RSX-11S system is larger than the checkpoint space 
inside the file. Typically, this indicates that the partition size in your PAR= 
statement is smaller than the actual size of the partition in the RSX-11S 
system. Although the load size of a task may be much smaller than its 
partition, the entire partition is transferred during checkpoint operations. 
Rebuild the task with the exact partition size from the RSX-11S system. 


4.3.4 Checkpointing RSX—11S Tasks 

Checkpointing allows the execution of a task to be interrupted when a higher 
priority task installed in the same partition becomes active. The software 
writes the interrupted task from RSX-11S memory to a checkpoint file on the 
host (Checkpoint Write) and then it loads the higher priority task into the 
partition and activates it. When the priority task exits, the software restores 
the interrupted task into main memory (Checkpoint Read), where it continues 
executing. 

Note that checkpointing implies that a job is already running in the partition. 
Checkpoint space must be allocated inside the task being loaded downline 
(through the /AL switch during RSX-11S task build). 


4.3.5 Overlaying RSX—11S Tasks 

Overlaying allows the execution of segments of a task in order to reduce the 
memory or address space requirements for that task to run on an RSX-11S 
system. SLD and HLD handle the reading of overlay segments by satellite 
systems. 


4.4 Connection to Remote Console 

DECnet-VAX allows you to set up a logical connection between your 
VAX/VMS node and the console interface on certain unattended nodes, 
in effect permitting your terminal to act as the console for the remote system. 
For example, your terminal can act as the console for the DIGITAL Ethernet 
Communications Server (DECSA) hardware and its resident software, such as 
the Router Server. The console carrier requester on the host connects to the 
console carrier server on the server. 
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You can set up the logical connection to the console using the remote console 
facility (RCF). Both your host node and the target node (that is, the server 
node) must be on the same Ethernet. You can use the RCF to force a crash 
if the server node should become unresponsive. (To determine how to force 
a crash, see the appropriate documentation for the particular server product.) 
RCF also permits debugging under special circumstances. 

To use the RCF, you must be sure the console carrier server image and its 
loader file are present in the system directory on the host node. (The file 
name of the console carrier server image is PLUTOCC.SYS and that of the 
loader is PLUTOWL.SYS.) To invoke RCF, specify either the CONNECT 
NODE or CONNECT VIA command. VAX/VMS then uses the loader 
file to downline load the console carrier server image into the Ethernet 
Communications Server hardware unit. 

Use the CONNECT NODE command if the name of the target node is 
known. If the target node's service password and service circuit are defined 
in the host node's volatile database, you can use these default values. If the 
Ethernet hardware address of the server node is not defined in the volatile 
database, you must specify the PHYSICAL ADDRESS parameter in the 
CONNECT NODE command. Should you specify the Ethernet physical 
address of the target node, DECnet-VAX attempts to use it to load the image 
file. If you do not supply an Ethernet address, DECnet-VAX derives an 
Ethernet physical address from the target node number, first attempting to 
use this address, and then attempting to use the Ethernet hardware address. 

To define default information for the target node in the volatile database, 
use the NCP command SET NODE to specify the SERVICE PASSWORD, 
SERVICE CIRCUIT, and HARDWARE ADDRESS parameters for the target 
node. You can override the target node parameter values currently defined in 
the volatile database by specifying new values in the CONNECT command. 

For example, to connect your VAX/VMS terminal to the console interface on 
server node RTRDEV, whose Ethernet physical address on circuit UNA-0 is 
AA-00-04-00-38-00, issue the command 

NCP> CONNECT NODE RTRDEV SERVICE PASSWORD FEFEFEFEFEFEFEFE - 
_ SERVICE CIRCUIT UNA-0 PHYSICAL ADDRESS AA-00-04-00-38-00 

Use the CONNECT VIA command if the node name of the target node is not 
known. In this command, you must specify the service circuit over which 
the logical connection is to be made and the Ethernet physical address of the 
target node. 

If you have not defined the hardware address of the server node in the 
volatile database and have not specified the Ethernet physical address of the 
node in the CONNECT command, DECnet-VAX displays an error message 
on your terminal as follows: 

Hardware address required 

The above message indicates that you must specify an Ethernet address for 
the target node in your CONNECT command, since no hardware address is 
available in the volatile database. 

In addition to the messages DECnet-VAX NCP or MOM may issue during 
downline loading of the console carrier server code, other messages described 
below may be issued when you attempt to connect to a remote console: 

Console in use 
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The remote console has already been reserved for another purpose. Try to 
make the connection later. 

Console connected (press CTRL/D when finished) 

The RCF is now ready for use. CTRL/B is used to pass a break character to 
the remote console. CTRL/D terminates the console session and causes the 
NCP prompt to be displayed. 

Target does not respond 

The remote console is supposed to respond quickly to inputs but is not doing 
so, or no connection can be made. 
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Configuration of a Network 


This chapter explains how to set up your VAX/VMS system for use in a 
DECnet-VAX network and provides sample configuration examples for 
various types of networks. 


5.1 Prerequisites for Establishing a Network 

Before configuring your DECnet-VAX node, you need to satisfy certain 
prerequisites for DECnet-VAX operation, such as setting up user accounts and 
directories, defining user privileges, and installing the key to your DECnet- 
VAX license. (Note that a DECnet-VAX license is required only if you are 
planning to run DECnet in a multinode environment.) 

If you are configuring VAX PSI, you must install it and define the privileges 
required for VAX PSI operation. If you are configuring VAX PSI in multihost 
mode (instead of native mode), you must install the VAX PSI multihost 
software on the VAX/VMS connector node that will serve as an X.25 
gateway, and the VAX PSI Access software on each host node that will 
use the connector node. 


5.1.1 User Accounts and Directories 

In addition to creating normal user accounts in the user authorization file 
(UAF), you should also create a default nonprivileged DECnet account that 
can be used for activating network objects on the local node. DECnet-VAX 
uses the access privileges of this account when access control information has 
not been explicitly supplied by the network user. Section 3.13 discusses 
access control and the use of default accounts. Refer to the VAX/VMS 
System Manager's Reference Manual for a description of how to create and 
use directories. 

The following example illustrates commands to establish a default 
nonprivileged DECnet account. If you use NETCONFIG.COM to configure 
your node and request a default nonprivileged DECnet account, the account 
will be created for you automatically (see Section 5.2.1.2). 

$ SET DEFAULT SYS$SYSTEM 
$ RUN AUTHORIZE 

UAF>ADD NETN0NPRIV/PASSW0RD=N0NPRIV/DEVICE=DISK$USER1:- 
_ /DIRECTORY=[NETUSER]/UIC=[200.200]/PRIVILEGE=(TMPMBX.NETMBX)- 
_ /FLAGS=(CAPTIVE)/NOBATCH/NOINTERACTIVE/LGICMD=NL: 

UAF>EXIT 

$ CREATE/DIRECTORY DISK$USER1:[NETUSER]/0WNER_UIC=[200.200] 

Note that you must substitute your own device name in place of DISK$USER1 
when you set up the default nonprivileged DECnet account. 

If you are configuring VAX PSI, ensure that you have the necessary PSI 
accounts, and the required directories associated with these PSI accounts, 
which will be used for incoming calls to your local DTE. You should also 
specify account information to activate objects at the local DTE for use by 
VAX PSI. 
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5.1.2 Required Privileges 

To perform any kind of network activity, a process must have the privileges 
required to access the network processes involved in the activity requested. 

As system manager, you define a user's privileges in the UAF. The privileges 
listed in Table 5-1 are at times required by the Network Management Listener 
(NML) and by those users of DECnet-VAX who are running NCP. The 
privileges listed in Table 5-2 are those required at times by both network 
users and system managers for VAX PSI operations. 


Table 5-1 

Required DECnet-VAX Privileges 

Privilege 

Description 

ACNT 

Allows you to create subprocesses or detached processes in 
which accounting is disabled. ACNT is required to start the 
network. 

BYPASS 

Allows you to view passwords that would not otherwise be 
displayed by the NCP commands SHOW or LIST. 

CMKRNL 

Allows a process to change its access mode to kernel, execute 
a specified routine, and then return to its original access mode. 
Specifically, you need CMKRNL to start the network. 

DETACH 

Allows you to create detached processes by executing the 
SCREPRC system service. DETACH is required to bring up the 
network. 

NETMBX 

Allows you to assign a channel to the NET device. This privilege 
is required to create a logical link or to perform any ACP control 
QIO functions. NETMBX is the minimum requirement for all 
accounts running network programs. 

OPER 

Allows you to perform certain operator functions such as 
modifying the configuration database. (Refer to the VAX/VMS 
System Manager's Reference Manual for a detailed explanation 
of the functions available under this privilege.) NML requires 
this privilege to modify any network parameters in the volatile 
database. 

TMPMBX 

Allows you to create temporary mailboxes. If you have this 
privilege, you can use the SCREMBX and SASSIGN system 
services to create a temporary mailbox and assign an I/O 
channel for task-to-task communication. Unlike a permanent 
mailbox, which must be explicitly deleted, a temporary mailbox is 
automatically deleted when no more channels are assigned to it. 
TMPMBX is required for the default accounts and to run both NML 
and NCP. 

SYSNAM 

Allows you to declare a name or object number in a user task (see 
Chapter 8 for information on user tasks). 

SYSPRV 

Allows you to access the permanent database. 
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Table 5-2 

Required VAX PSI Privileges 

Privilege 

Description 

SECURITY 

Allows a system manager to access the VAX PSI security 
databases. 

DIAGNOSE 

Allows a system manager to use diagnostic functions. You can 
use it to run online diagnostic programs. DIAGNOSE is required if 
you want to perform line loop tests. 

NETMBX 

Allows a network user to assign a channel to the NW device. 

This channel is required to set up virtual circuits or to perform 
any ACP control QIO functions. Either NETMBX privilege or the 
PSI$X25_USER right is required for processes running network 


programs. 

OPER 

Allows a system manager to use the NCP commands. A detailed 
explanation of the NCP functions available under this privilege 
is given in the VAX/VMS Network Control Program Reference 
Manual. 

TMPMBX 

Allows a network user to create temporary mailboxes, that is, use 
the $ASSIGN system service to create a temporary mailbox and 
assign an I/O channel for DTE-to-DTE communication. Unlike a 
permanent mailbox, which must be deleted explicitly, a temporary 
mailbox is deleted automatically when no more channels are 
assigned to it. 

SYSPRV 

Allows a system manager to create and display objects. 


Refer to Section 3.13 for a further discussion of network user privileges and 
their function in relation to overall network security. 


5.2 Configuration Procedures 

Before you install DECnet-VAX on your system, there are certain tasks 
that you, as system manager, must complete to prepare for a networking 
environment. 

You must configure your DECnet-VAX permanent database. You can use 
the interactive procedure NETCONFIG.COM provided by Phase IV DECnet- 
VAX to do this. NETCONFIG.COM will prompt you for all the information 
needed to configure the permanent database and set up an optional default 
nonprivileged DECnet account on your system. If you choose not to use 
NETCONFIG.COM, you must use NCP commands to build the permanent 
database. Alternatively, you can use NCP commands to tailor the permanent 
database created by NETCONFIG.COM to your own needs. Also, you can 
use the NCP command COPY KNOWN NODES to build or update the 
remote node entries in your node database. Special considerations that apply 
to configuration of the permanent database for a VAXcluster node are given 
in Section 5.4.5. 

You may have to perform additional configuration tasks depending upon your 
specific network requirements. If you plan to run DECnet-VAX over a Cl, 
you must install the DECnet driver CNDRIVER. If you will be using some of 
your terminal lines as DECnet-VAX lines, you must install the asynchronous 
DDCMP driver NODRIVER and set up the static or dynamic asynchronous 
lines. Section 5.2.2 describes these tasks in detail. 

Refer to the MicroVMS User's Manual if you will be configuring one or more 
MicroVMS systems as part of the network. 
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If VAX PSI is to be run, the system manager is responsible for configuring 
VAX PSI for the local DTEs. This involves supplying information about 
various VAX PSI components, such as circuits, lines, modules, and objects. 
The information is contained in the DECnet-VAX configuration database for 
the local node (if both DECnet-VAX and PSI are configured) and in the PSI 
configuration database for the local DTEs. You use NCP commands to supply 
information to the configuration database. 


5.2.1 Using NETCONFIG.COM 

NETCONFIG.COM performs the following steps: 

1 Prompts you for the name and address of your node and asks whether or 
not you want a default nonprivileged DECnet account and whether you 
want to operate as a router or an end node. 

2 Determines which DECnet devices you have on your system. 

3 Creates and displays the NCP and DCL commands required to configure 
your DECnet-VAX node. 

4 Executes the commands displayed, if they are accepted, setting the 
appropriate parameters in the permanent configuration database at your 
node. This procedure establishes all databases (executor, line, circuit, 
object, logging) except for the remote node database. 

Use of this optional procedure is recommended when you are bringing up a 
new system as a DECnet-VAX node or when you wish to completely revise 
the configuration database for a system that is already running DECnet-VAX. 

Specifically, if you are bringing up a new system, follow the steps below. 

1 Execute NETCONFIG.COM. 

2 Use NCP commands to modify or add parameters once the initial database 
is configured. To make changes in or add DECnet accounts, use the DCL 
command AUTHORIZE. 

3 Set up the remote node database using NCP DEFINE NODE commands. 

4 Execute STARTNET.COM to bring up your DECnet-VAX node (see 
Section 6.2). 

If you are running DECnet-VAX on a node and wish to completely revise 
all permanent configuration databases except the remote node database, 
you should execute NETCONFIG.COM. To make any further alterations 
in the databases and DECnet accounts, use NCP and the DCL command 
AUTHORIZE. 

If you are running DECnet-VAX and wish to preserve the existing permanent 
database, do not use NETCONFIG.COM. Use NCP commands to make any 
desired changes in the database. 
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5.2.1.1 ExecutingNETCONFIG.COM 

You must have system privilege (SYSPRV) to execute NETCONFIG.COM. To 
invoke the command procedure, issue the command 

$ <5SYS$MANAGER:NETCONFIG.COM 

The only information you must supply to the procedure is the node name 
and node address of your system. The node name is a string of up to six 
alphanumeric characters, containing at least one alphabetic character. The 
node address is a numeric value in the form 

area-number.node-number 

The number to the left of the period designates the area in which the node is 
grouped (in the range from 1 to 63) and the number to the right of the period 
designates the node's unique address within the area (in the range from 1 to 
1023). If the network is not divided into two or more areas, you do not have 
to provide the area number; the system will supply the default area number 
1 . 

The procedure also asks whether you want a default nonprivileged DECnet 
account to be established for you. If you indicate yes (or take the default YES 
by pressing the RETURN key), the procedure displays the DCL AUTHORIZE 
command that would create a default nonprivileged DECnet account with a 
null password and a UIC of [376,376]. (Note that you can change this UIC 
value or other account parameters by using the Authorize Utility once the 
node is configured.) 

NETCONFIG.COM then asks if you want the executor node to function as a 
router. If you type NO (or take the default NO by pressing the RETURN key) 
in response to this question, the executor node will be set up as a nonrouting 
node. 

NETCONFIG.COM automatically determines which DECnet devices exist 
on your system for use in building the line and circuit permanent databases. 
NETCONFIG.COM then uses the information you supply and the information 
it obtains about the system to create all the commands necessary to configure 
your system as a DECnet-VAX node, and displays these commands for your 
approval (see example below). The commands define the permanent database 
parameters for the executor; all lines, circuits, and objects; and all logging 
monitor events. The commands do not define the database for any remote 
node. 

Inspect the displayed commands. NETCONFIG.COM will ask if you want to 
configure using these commands. If you answer yes, the procedure establishes 
the permanent configuration database and default nonprivileged DECnet 
account (if you requested it). If you answer no, the procedure returns a 
message indicating no changes have been made. 

Once the permanent database is established, you have the option of using 
NCP commands to alter the parameters to correspond more closely to your 
configuration requirements. 

If you use NETCONFIG.COM to establish the configuration database for 
a system that will be using asynchronous lines (for example, a Micro VMS 
system with a terminal line), NETCONFIG.COM will not configure 
the asynchronous circuit and line parameters automatically. Instead, 
NETCONFIG.COM will issue a message indicating that no circuits or lines 
have been configured. You must set up the asynchronous lines separately 
(see Section 5.2.2.2). 
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If you have purchased a DECnet-VAX license and have not yet installed the 
key for that license, do so now. 

After configuring your DECnet-VAX system, start up the network by issuing 
the command 

$ QSYS$MANAGER:STARTNET 

To ensure that the installation is successful, you can use the User 
Environment Test Package (UETP) to test DECnet. The test procedure is 
described in the Guide to VAX/VMS Software Installation. 


5.2.1.2 NETCONFIG.COM Example 

The following example shows the interactive dialog that is displayed when 
you execute NETCONFIG.COM to configure node CHCAGO 

DECnet-VAX network configuration procedure 

This procedure will help you define the parameters needed to get 
DECnet running on this machine. You will be shown the changes before 
they are actually executed, in case you wish to perform them manually. 

What do you want your DECnet node name to be? CHCAGO 

What do you want your DECnet address to be? 2.37 

Do you want a default DECnet account? [YES] 

Do you want to operate as a router? [NO (nonrouting)] 

Here are the commands necessary to set up your system. 


RET 

RET 


$ RUN SYS$SYSTEM:NCP 

PURGE EXECUTOR ALL 
PURGE KNOWN LINES ALL 
PURGE KNOWN CIRCUITS ALL 
PURGE KNOWN LOGGING ALL 
PURGE KNOWN OBJECTS ALL 

PURGE MODULE CONFIGURATOR KNOWN CIRCUITS ALL 
$ DEFINE/USER SYS$OUTPUT NL: 

$ DEFINE/USER SYS$ERROR NL: 

$ RUN SYS$SYSTEM:NCP 

PURGE NODE 2.37 ALL 
PURGE NODE CHCAGO ALL 
$ RUN SYS$SYSTEM:NCP 

DEFINE EXECUTOR ADDRESS 2.37 STATE ON 
DEFINE EXECUTOR NAME CHCAGO 
DEFINE EXECUTOR MAXIMUM ADDRESS 255 
DEFINE EXECUTOR ROUTING TYPE NONROUTING IV 
DEFINE EXECUTOR NONPRIVILEGED USER DECNET 
$ DEFINE/USER SYSUAF SYS$SYSTEM:SYSUAF.DAT 
$ RUN SYS$SYSTEM:AUTHORIZE 

ADD DECNET /OWNER="DECNET DEFAULT" - 
/PASSWORD 3 "" - 

/UIC=[376,376] /ACCOUNT=DECNET - 
/DEVICE=SYS$SYSDEVICE: /DIRECTORY 3 [DECNET] - 
/PRIVILEGE 3 (TMPMBX,NETMBX) 

/FLAGS 3 (CAPTIVE)/NOBATCH/NOINTERACTIVE /LGICMD=NL: - 
/NOBATCH /NOINTERACTIVE 

$ CREATE/DIRECTORY SYS$SYSDEVICE:[DECNET] /OWNER 3 [376,376] 
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$ RUN SYS$SYSTEM:NCP 

DEFINE LINE CI-0 STATE ON 

DEFINE LINE UNA-0 STATE ON 

DEFINE CIRCUIT UNA-0 STATE ON COST 3 

DEFINE LINE DMC-0 STATE ON 

DEFINE CIRCUIT DMC-0 STATE ON COST 5 

DEFINE LINE DMC-1 STATE ON 

DEFINE CIRCUIT DMC-1 STATE ON COST 5 

DEFINE LOGGING MONITOR STATE ON 

DEFINE LOGGING MONITOR EVENTS 0.0-9 

DEFINE LOGGING MONITOR EVENTS 2.0-1 

DEFINE LOGGING MONITOR EVENTS 4.2-13,15-16,18-19 

DEFINE LOGGING MONITOR EVENTS 5.0-18 

DEFINE LOGGING MONITOR EVENTS 128.0-4 


Do you want to go ahead and do it? [YES]: NO 

No changes have been made. 


5.2.2 Tailoring the Configuration Database 

If you do not choose to use NETCONFIG.COM to build the network 
configuration in the permanent database, you may instead configure the 
network using individual NCP commands. Examples of various configuration 
procedures are given in Section 5.3. NCP can also be used to add or delete 
entries in an existing permanent database. 

Following are two examples of changes made to the network configuration 
that require corresponding modification of the permanent database. 

• Running DECnet over the CL The driver CNDRIVER must be loaded 
on the system and all Cl lines and circuits must be defined in the 
configuration database. 

• Running DECnet over terminal lines. The terminal driver NODRIVER 
must be loaded on the system, terminal lines must be converted to 
DDCMP lines, and all DDCMP lines and circuits must be defined in the 
configuration database. 

The procedures for handling these changes are described in detail in the 
following sections. 


5.2.2.1 Running DECnet over the Cl 

To use the CI750 or CI780 as a DECnet device on your VAX/VMS system, 
you must first install CNDRIVER, the DECnet driver associated with the CL 
To load CNDRIVER, add the following commands to the LOADNET.COM 
command procedure in the SYS$MANAGER directory. 

$ RUN SYS$SYSTEM:SYSGEN 
CONNECT CNAO/NOADAPTER 

You are now ready to run DECnet over the CI. The following example 
illustrates how to use NCP commands to define the CI line and one or more 
CI circuits in the permanent database. 

$ RUN SYS$SYSTEM:NCP 
NCP>DEFINE LINE CI-0 STATE ON 

NCP>DEFINE CIRCUIT CI-0.0 TRIBUTARY 0 STATE ON 
NCP>DEFINE CIRCUIT CI-0.1 TRIBUTARY 1 STATE ON 


NCP> EXIT 

$ 
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5.2.2.2 Running DECnet over Terminal Lines 

To use lines connected to terminal ports as DECnet communications lines, 
you must load the asynchronous DDCMP driver NODRIVER, set up the 
terminal lines to be converted to asynchronous DDCMP lines, and specify the 
appropriate lines and circuits in the NCP configuration database. The steps 
in converting terminal lines to asynchronous lines depend on the type of line 
you want to set up: 

• Static asynchronous DDCMP line: a line permanently configured as a 
DECnet line 

• Dynamic asynchronous DDCMP line: a line that is switched from terminal 
to DECnet use for the duration of a dialup call 

Procedures for installing and shutting down each of these types of lines are 
described below. 

Because dialup lines are more prone to noise problems than dedicated 
synchronous lines that do not use modems, it is recommended that the 
executor buffer size and segment buffer size be set to a value of 192 for any 
end node that is connected to its router by a dialup line. Use of a relatively 
small buffer size will reduce the effect of buffer retransmission on overall 
throughput. 


5.2.2.3 Installing Static Asynchronous Lines 

The following procedures illustrate the steps in setting up and shutting down 
static asynchronous lines on your system. 

Setting Up Static Asynchronous DDCMP Lines 

The steps necessary to set up lines connected to terminal ports on your 
system for use as static asynchronous DECnet lines are as follows: 

1 Load the asynchronous DDCMP driver NODRIVER by adding the 
following commands to the LOADNET.COM command procedure in 
the SYS$MANAGER directory or specifying the commands after the 
system is booted. 

$ RUN SYSISYSTEM:SYSGEN 
SYSGEN> CONNECT NOAO/NOADAPTER 

2 Choose the terminal lines on your system that you will use as DECnet 
lines. To convert a line to a static asynchronous DDCMP line, 

add the DCL command SET TERMINAL/PROTOCOL=DDCMP to 
LOADNET.COM in your SYS$MANAGER directory for each terminal 
line that will run DECnet. 

For example, to convert the terminal lines connected to ports TTAO and 
TXB7 on your system into DECnet lines with no modem control, add the 
following to LOADNET.COM: 

$ SET TERMINAL/PROTOCOL=DDCMP TTAO: 

$ SET TERMINAL/PROTOCOL=DDCMP TXB7: 

To convert the line connected to terminal port TXA1 (which can be used 
as a dialup line) to a DECnet line with modem control, add the following 
command to LOADNET.COM: 

$ SET TERMINAL/PERMANENT/MODEM/NOHANGUP/NOAUTOBAUD - 
_$ /NOTYPEAHEAD/PROTOCOL=DDCMP TXA1: 

Note that the line speed cannot be changed while the terminal line is in 
use as a DECnet communications line. 
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3 Use NCP commands to define all terminal lines and circuits in the 

configuration permanent database, as illustrated in the following example: 


$ RUN SYS$SYSTEM:NCP 

NCP> DEFINE LINE TT-0-0 STATE ON 

_ LINE SPEED 9600 

NCP> DEFINE CIRCUIT TT-0-0 STATE 

NCP> DEFINE LINE TX-1-7 STATE ON 

_ LINE SPEED 9600 

NCP> DEFINE CIRCUIT TX-1-7 STATE 


RECEIVE BUFFERS 4 - 
ON 

RECEIVE BUFFERS 4 - 
ON 


NCP> DEFINE LINE TX-1-1 STATE ON RECEIVE BUFFERS 4 - 

_ LINE SPEED 1200 

NCP> DEFINE CIRCUIT TX-1-1 STATE ON 

NCP> EXIT 

$ 


The lines are then turned on to the network. 


Reasons for Failure of Static Asynchronous Connections 

If static asynchronous DECnet lines are started but are left in the "ON - 
STARTING" state, check the following: 

• The line speeds or both ends of the connection must be set to the same 
value. 

• If you are using a dialup line, the modem characteristic must be set on the 
terminal before the line is switched to asynchronous DDCMP use. 

• If the network is divided into areas, the two nodes being connected must 
be in the same area or must be area routers. 

• Asynchronous DECnet requires that the parity on the asynchronous line 
be set to NONE and the terminal line be set up to use 8-bit characters. If 
you are using a non-VAX/VMS system, you must check that the terminal 
line is set to the correct parity. 

If your terminal line cannot be set up as a static asynchronous DDCMP line, 
check whether the following condition exists: 

• If data is stored in a type-ahead buffer associated with your terminal 
line, the line will come up as a terminal line even if a startup command 
procedure attempts to set it up as a DDCMP line. This generally occurs 
when the remote node is running and its asynchronous DDCMP line is 
on. The DDCMP start messages being transmitted will be stored in the 
type-ahead buffer for your line. Before you can start up your terminal line 
in DDCMP mode, you must terminate the process that has started and 
that owns your terminal line. 

Shutting Down Static Asynchronous DDCMP Lines 

To shut down a DECnet line and return it to a terminal line, specify the 
following commands: 

$ RUN SYS$SYSTEM:NCP 
NCP> SET LINE TT-0-0 STATE OFF 
NCP> CLEAR LINE TT-0-0 ALL 
NCP> SET CIRCUIT TT-0-0 STATE OFF 
NCP> CLEAR CIRCUIT TT-0-0 ALL 

To switch a line for which modem control was not enabled back to a terminal 
line, specify 

$ SET TERMINAL/PR0T0C0L=N0NE TTAO: . 
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To switch a line for which modem control was enabled back to a terminal 
line, specify 

$ SET TERMINAL/PERMANENT/AUTOBAUD - 
_$ TYPEAHEAD/PROTOCOL=NONE TXA1: 


5.2.2.4 Installing Dynamic Asynchronous Lines 

To make a temporary connection to another node over an asynchronous 
connection (for example, a telephone line), the terminal lines at each node 
may be switched to dynamic asynchronous DDCMP lines for the duration of 
the connection. The procedure for establishing a dynamic connection, reasons 
why the connection might fail, and the actions that shut down the lines are 
described below. Dynamic switching is described in detail in Chapter 2. 

Setting Up Dynamic Asynchronous DDCMP Lines 

The steps necessary to set up a dynamic connection, switching lines connected 
to terminal ports to dynamic asynchronous DECnet lines, are outlined below. 
This procedure illustrates commands used if a local Micro VMS system 
(MYNODE) is establishing a dynamic connection with a remote VAX/VMS 
system (BIGVAX). 

1 The system manager at each node must load the asynchronous 
DDCMP driver NODRIVER by adding the following commands to the 
LOADNET.COM command procedure in the SYS$MANAGER directory or 
specifying the commands after the system is booted. 

$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> CONNECT NOAO/NOADAPTER 

2 The system manager at each node must install the shareable image 
DYNSWITCH as follows: 

$ INSTALL:=$SYS$SYSTEM:INSTALL 
$ INSTALL/COMMAND 

INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE - 
_ /PROTECT/HEADER/OPEN 
INSTALL> EXIT 

Note that if the image DYNSWITCH is not installed on the system, 
dynamic switching of lines is implicitly disabled. 

3 The system manager at the remote node, BIGVAX, must enable the use of 
virtual terminals with these commands: 

$ RUN SYS$SYSTEM:SYSGEN 

SYSGEN> CONNECT VTAO/NOADAPTER/DRIVER-TTDRIVER 

The system manager must also enable the disconnect option for the 
terminal by specifying the following for the terminal: 

$ SET TERMINAL/PERMANENT/DISCONNECT TTB1: 

(For further information on using virtual terminals, refer to the VAX/VMS 
System Manager's Reference Manual.) 

4 The user at the local system, MYVAX, performs the following steps: 
a Log in to the local system 

b Specify the following to establish the system as a terminal emulator 
(TTA1 identifies the terminal port on the local system through which 
the dynamic connection will be made): 

$ SET HOST/DTE TTA1: 
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(You can optionally include the /DIAL qualifier in the SET HOST 
command to cause automatic dialing of the modem to the remote 
node). 

c Dial in to the remote system. 

d Log in to your account on the remote node BIG VAX. 

e If your local terminal emulator supports automatic dynamic switching 
of terminal lines to asynchronous DDCMP lines, specify the following 
to initiate automatic dynamic switching at both ends of the connection: 

$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET 

You will receive the following message when DECnet is started at the 
local node: 

7, REM-S-END - control returns to local-node-name: 

$ 

Use the line for network operations when you see the local system 
prompt ($). 

f If your local terminal emulator does not support automatic switching, 
specify the /MANUAL qualifier in the SET TERMINAL command: 

$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET/MANUAL 

You will receive the following message from the remote system: 

7. SET-I-SWINPRG The line you are currently logged 
over is becoming a DECnet line 

Exit the terminal emulator and specify the following to switch your 
terminal line manually: 

$ SET TERMINAL/PROTOCOL=DDCMP TTA1: 

Enter the following NCP commands to turn on your line and circuit. 
DECnet is then started at the local node. 

$ RUN SYS$SYSTEM:NCP 

NCP>SET LINE TT-0-1 RECEIVE BUFFERS 4 STATE ON 
NCP>SET CIRCUIT TT-0-1 RECEIVE BUFFERS 4 STATE ON 
NCP>EXIT 

Note that the SET TERMINAL command is a VAX/VMS DCL command. 
If you are on a non-VAX/VMS node, you should specify the equivalent 
function for your system. 

Reasons for Failure of Dynamic Asynchronous Connections 

If dynamic switching is being performed and the asynchronous DECnet 
connection is not made, first check that the following conditions exist: 

• DECnet must be started on both nodes. 

• The asynchronous DDCMP class driver (NODRIVER) must be loaded by 
means of SYS$SYSTEM:SYSGEN at each node. 

• The dynamic switch image (DYNSWITCH) must be installed by means of 
SYS$SYSTEM:INSTALL at each VAX/VMS node. 

• Virtual terminals must be enabled both on the remote node and, in 
particular, for the terminal over which you are logged in. The terminal 
line at the remote node must have the attribute DISCONNECT set. 
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• After you issue a SET TERMINAL command with the /MANUAL 
qualifier, you must specify NCP commands to turn on the DECnet line 
within approximately four minutes or the line will return to terminal 
mode. 

If the dynamic asynchronous lines are started but are left in the "ON - 
STARTING" state, check the following: 

• If the network is divided into areas, the two nodes being connected must 
be in the same area or must be area routers. 

• The routing initialization passwords on each node must be set correctly 
(see Section 3.13.1). 

• The INBOUND parameter for the local node entry must be set correctly in 
the node database at the remote node (see Section 3.13.3). 

• Asynchronous DECnet requires that the parity on the asynchronous line 
be set to NONE and the terminal line be set up to use 8-bit characters. If 
you are using a non-VAX/VMS system, you must check that the terminal 
line is set to the correct parity. 

Shutting Down Dynamic Asynchronous Lines 

You have two options for ending a dynamic connection: 

• Break the telephone connection. 

• Specify one of the following NCP commands (either command will cause 
both line and circuit entries to be cleared in the database): 

NCP> SET LINE TT-0-0 STATE OFF 
NCP> SET CIRCUIT TT-0-0 STATE OFF 

The results of these commands are different depending on the side of the 
connection from which they are entered. On the side where the commands 
are executed (the local node), the port will be immediately switched to the 
terminal driver. On the other side (the remote node), the line will remain in 
the ON-STARTING state for approximately three minutes and then will be 
switched to the terminal port. 

Note that if you specified the /NOHANGUP qualifier in the SET TERMINAL 
command with which you initiated dynamic switching, the modem carrier 
signal will not be dropped when you shut down the DECnet line or circuit. 
The carrier signal will be broken when you hang up the telephone. 

If you specify the SET TERMINAL command with the /MANUAL qualifier 
to switch the terminal line manually, you can abort the switch by pressing 
CTRL/C or CTRL/Y. 


5.3 Network Configuration Examples 

This section illustrates how you can use NCP commands to build your 
network configuration in the permanent database. Included are examples 
of the NCP commands you would use to obtain the following network 
configurations: 

• Synchronous DDCMP point-to-point configuration 

• DDCMP multipoint configuration 

• Static asynchronous DDCMP point-to-point configuration 
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• Dynamic asynchronous DDCMP point-to-point configuration 

• Ethernet configuration 

• X.25 DLM configuration 

• X.25 native mode configuration 

• X.25 multihost mode configuration 

• X.25 multinetwork configuration 

Note that the configuration examples in this section assume single-area 
networks using the default area 1. For an example of the NCP commands 
used to configure a multiple-area network, see Section A.3. 

Combine the appropriate NCP commands in a command file that reflects 
your network configuration; then edit and run this procedure as many times 
as necessary to properly build the permanent database corresponding to your 
configuration and needs. Once you have configured the permanent database, 
invoke SYS$MANAGER:STARTNET.COM to load these parameters into the 
volatile database and bring up the network. 


5.3.1 Synchronous DDCMP Point-to-Point Network Example 

The example below builds a database for a network configuration of four 
nodes, connected by a DMC11, DMP11 or DMF32 line and circuit. 

Figure 5-1 A Synchronous DDCMP Point-to-Point Network 
Configuration 


CHCAGO 



NEWARK 

ATLNTA 

TAMPA 


ZK-1852-84 


Use the following NCP commands to configure the DDCMP point-to-point 
network. Note that node NEWARK is a nonrouting RSX-11S system to which 
node CHCAGO will perform a downline load. 


Define executor-specific parameters for local node CHCAGO. 
The TYPE parameter for the executor node defaults to 
ROUTING IV. 

DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 
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Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 

DEFINE EXECUTOR NAME CHCAGO - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define parameters for remote node NEWARK (a nonrouting 
RSX-11S system). CHCAGO will be the load host for NEWARK. 


DEFINE NODE 2 


NAME NEWARK - 
HOST NODE CHCAGO - 
LOAD FILE NODIIS.SYS - 
NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV - 
SERVICE CIRCUIT DMC-0 - 
SERVICE PASSWORD FE - 
SECONDARY LOADER SECDMC.SYS 
TERTIARY LOADER TERDMC.SYS 



Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 
each remote node when it receives an inbound connect request. 


DEFINE NODE 3 
DEFINE NODE 4 


NAME ATLNTA 
NAME TAMPA 


Define parameters for line/circuit DMC-0 to node NEWARK. 

Because this node will be loaded downline, the service 
parameters must be set up. 


DEFINE LINE DMC-0 PROTOCOL DDCMP POINT - 

SERVICE TIMER 4000 - 

STATE ON 


DEFINE CIRCUIT DMC-0 


SERVICE ENABLED 
STATE ON 


Define parameters for line/circuit DMF-0 to node ATLNTA. 


(Give this line more receive buffers because it has a faster 
connection.) 


DEFINE LINE DMF-0 PROTOCOL DDCMP POINT - 

RECEIVE BUFFERS 8 - 

STATE ON 

DEFINE CIRCUIT DMF-0 STATE ON 


Define parameters for line/circuit DMP-0 to node TAMPA. 


DEFINE 

LINE 

DMP-0 

PROTOCOL DDCMP POINT 
STATE ON 

DEFINE 

CIRCUIT 

DMP-0 

STATE ON 
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The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 

Define transmitter-related logging parameters. 

DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 

DEFINE LOGGING MONITOR STATE ON 


5.3.2 DDCMP Multipoint Network Example 

This example builds a database for a network configuration of five nodes, 
connected by a combination of DMC, DMF, and DMP lines and circuits. 

Figure 5-2 A DDCMP Multipoint Network Configuration 


CHCAGO 



PHILA 

ATLNTA 


TAMPA MIAMI 


ZK-1853-84 


Use the following NCP commands to configure the DDCMP multipoint 
network: 


Define executor-specific parameters for local node CHCAGO. 
The TYPE parameter for the executor node defaults to 
ROUTING IV since a full function license is installed. 


DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 
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Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 

DEFINE EXECUTOR NAME CHCAGO - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 
each remote node when it receives an inbound connect request. 


DEFINE NODE 2 
DEFINE NODE 3 
DEFINE NODE 4 
DEFINE NODE 5 


NAME PHILA 
NAME ATLNTA 
NAME TAMPA 
NAME MIAMI 



Define parameters for line/circuit DMC-0 to node PHILA. 

DEFINE LINE DMC-0 PROTOCOL DDCMP POINT - 

STATE ON - 

DEFINE CIRCUIT DMC-0 STATE ON 


Define parameters for line/circuit DMF-0 to node ATLNTA. 


DEFINE LINE DMF-0 
DEFINE CIRCUIT DMF-0 


PROTOCOL DDCMP POINT - 
STATE ON 

STATE ON 


Define parameters for line DMP-0 and circuits to nodes TAMPA 
and MIAMI. 


TAMPA is connected as tributary 3, DMP-O.0 
MIAMI is connected as tributary 4, DMP-O.1 


The DMP line runs at 56,000 bits per second, 
setting for the retransmit timer is 


The proper 


retransmit timer 


20,000 * buffer_size 
bps 



Thus, with a buffer size of 576, the retransmit timer should 
be 210 milliseconds. 


The dead timer is set to 30 seconds to avoid excessive delays 
when polling dead tributaries. The timer is set when a node 
goes down. 


DEFINE LINE DMP-O PROTOCOL DDCMP CONTROL 

DEAD TIMER 30000 - 

RECEIVE BUFFERS 6 - 

RETRANSMIT TIMER 210 - 
STATE ON 

DEFINE CIRCUIT DMP-O.0 COST 4 - 

STATE ON - 
TRIBUTARY 3 


DEFINE CIRCUIT DMP-O.1 


COST 4 - 

STATE ON - 
TRIBUTARY 4 


* 
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The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 


! Define transmitter-related logging parameters. 
DEFINE LOGGING MONITOR KNOWN EVENTS 

! 

! Define receiver-related logging parameters. 

j 

DEFINE LOGGING MONITOR STATE ON 


5.3.3 Static Asynchronous DDCMP Network Example 

The example below builds a database for a network configuration of four 
nodes, connected by a DMR11 line and two terminal lines converted to static 
asynchronous DECnet lines. 

Figure 5-3 A Static Asynchronous DDCMP Network 
Configuration 


CHCAGO 



ST PAUL 

YELLOW 

BLUE 


ZK-1854-84 


Use the following NCP commands to configure the DDCMP point-to-point 
network that includes static asynchronous lines. To establish the static 
asynchronous connections, nodes YELLOW and BLUE must also specify in 
their configuration databases the circuits and lines connecting them to node 
CHCAGO. Before issuing these commands, you should set up the terminal 
line with the appropriate characteristics. (See Section 5.2.2.3.) 


Define executor-specific parameters for local node 

CHCAGO. The TYPE parameter for the executor node defaults to 

ROUTING IV. 

DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 
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Define common node parameters for the local node. Be 
sure to add the NETNONPRIV user to your system 
authorization file by using the Authorize Utility. 

DEFINE EXECUTOR NAME CHCAGO - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remaining nodes. Note that no default 
outbound access control information is specified. 
This assumes that the default access control 
information will be supplied by each remote node 
when it receives an inbound connect request. 

DEFINE NODE 2 NAME STPAUL 

DEFINE NODE 3 NAME YELLOW 

DEFINE NODE 4 NAME BLUE 


Define parameters for 
STPAUL. 

DEFINE LINE DMR-0 
DEFINE CIRCUIT DMR-0 


line/circuit DMR-0 to node 

PROTOCOL DDCMP POINT 
STATE ON 

STATE ON 


Define parameters for line/circuit TT-0-0 to node 
YELLOW. 

DEFINE LINE TT-0-0 RECEIVE BUFFERS 4 - 

STATE ON - 
LINE SPEED 9600 

DEFINE CIRCUIT TT-0-0 STATE ON 


Define parameters for line/circuit TX-1-7 to node 
BLUE. 

DEFINE LINE TX-1-7 RECEIVER BUFFERS 4 - 

STATE ON - 

LINE SPEED 1200 

DEFINE CIRCUIT TX-1-7 STATE ON 


The object database does not need to be defined 
because it defaults to the standard list of objects 
known to VAX/VMS. 


Define transmitter-related logging parameters. 


DEFINE LOGGING MONITOR KNOWN EVENTS 


Define receiver-related logging parameters. 


DEFINE LOGGING MONITOR STATE ON 


5.3.4 Dynamic Asynchronous DDCMP Network Example 

The example below indicates the NCP commands to configure two nodes, 
connected by a terminal line converted to a dynamic asynchronous DECnet 
line. Before issuing these commands, refer to the procedure for installing 
dynamic asynchronous lines in Section 5 . 2 . 2 . 4 . 
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Figure 5-4 A Dynamic Asynchronous DDCMP Network 
Configuration 


BIGVAX MYNODE 



5.3.4.1 Node BIGVAX Database 

Use the following NCP commands to configure the dynamic asynchronous 
DDCMP connection from node BIGVAX to node MYNODE. This example 
assumes BIGVAX is a router. 


Define executor-specific parameters for local node 
BIGVAX. 

DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 

Define common node parameters for the local node. Be 
sure to add the NETNONPRIV user to your system 
authorization file by using the Authorize Utility. 

DEFINE EXECUTOR NAME BIGVAX - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remote node. You must use the INBOUND 
parameter to check whether dialup node MYNODE will 
operate as an end node or as a router. As an added 
security feature for a node using a dynamic asynchronous 
communications line, you must also specify a receive 
password for node MYNODE. This will be compared with 
the transmit password supplied by MYNODE when it 
issues the connect request. 

DEFINE NODE 2 NAME MYNODE - 

INBOUND ENDNODE - 
RECEIVE PASSWORD 10101010 

You do not need to define parameters for a 
line/circuit to node MYNODE. These parameters are 
provided automatically by the system when the dynamic 
connection is initiated. 
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The object database does not need to be defined 
because it defaults to the standard list of objects 
known to VAX/VMS. 


Define transmitter-related logging parameters. 
DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 
DEFINE LOGGING MONITOR STATE ON 


5.3.4.2 Node MYNODE Database 

Use the following NCP commands to configure the dynamic asynchronous 
DDCMP connection from node MYNODE to node BIGVAX. This example 
assumes that MYNODE is an end node and that the dynamic line is a slow 
(1200 baud) modem line. 


Define executor-specific parameters for local node 
MYNODE. 


DEFINE EXECUTOR ADDRESS 2 - 

BUFFER SIZE 192 - 

SEGMENT BUFFER SIZE 192 - 
STATE ON - 
TYPE NONROUTING 

Define common node parameters for the local node. 

Be sure to add the NETNONPRIV user to your system 
authorization file by using the Authorize Utility. 

DEFINE EXECUTOR NAME MYNODE - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remote node. You must specify a transmit 
password which matches the receive password in the 
remote node database on node BIGVAX. 


DEFINE NODE 1 NAME BIGVAX - 

TRANSMIT PASSWORD 10101010 


You do not need to define parameters for a 
line/circuit to node BIGVAX. These parameters are 
provided automatically by the system when the dynamic 
connection is initiated. 


The object database does not need to be defined 
because it defaults to the standard list of objects 
known to VAX/VMS. 
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5.3.5 Ethernet Network Example 

This example builds a database for a network configuration of three nodes, 
connected by an Ethernet UNA line and circuit. 

Figure 5-5 An Ethernet Network Configuration 


UNA-0 



ROBIN THRUSH LARK 


ZK-1855-84 


* Use the following NCP commands to configure the node ROBIN database. 
Repeat the procedure to configure the databases for nodes THRUSH and 


LARK. 


Define executor-specific parameters for local node ROBIN. 
Note that the TYPE parameter for the executor node defaults 
to a node type that corresponds to the type of network 
license (router or end node) you have installed. 

DEFINE EXECUTOR ADDRESS 20 - 

BUFFER SIZE 576 - 

STATE ON 


Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 

DEFINE EXECUTOR NAME ROBIN - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 
each remote node when it receives an inbound connect request. 


DEFINE NODE 21 
DEFINE NODE 22 


NAME THRUSH 
NAME LARK 


Define parameters 


for line/circuit UNA-0. 
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DEFINE LINE UNA-0 STATE ON 

DEFINE CIRCUIT UNA-0 STATE ON 

The object database does not need to be defined because 
it defaults to the standard list of objects known to VAX/VMS. 

Define transmitter-related logging parameters. 

DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 

DEFINE LOGGING MONITOR STATE ON 


5.3.6 X.25 Data Link Mapping Example 

This example builds a database for a network configuration of three nodes, 
connected by a DMC11 line and circuit and an X.25 packet switching data 
network (PSDN). 

Figure 5-6 An X.25 Data Link Mapping Network Configuration 


CHCAGO 



X25-OUT 

I 

DTE 311111222333 



X25-INC 


SDIEGO 


BUFFLO 


ZK-1856-84 
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5.3.6.1 Node CHCAGO Database 

Use the following NCP commands to configure the node CHCAGO database. 


Set up the X.25 protocol module. 

DEFINE MODULE X25-PR0T0C0L - 

NETWORK TELENET PROFILE TELENET 

Define the line used to communicate with the X.25 network. 

DEFINE LINE DUP-0 NETWORK TELENET STATE ON 

Define the local DTE for node CHCAGO. 


DEFINE MODULE X25-PR0T0C0L - 

DTE 311111222333 - 

NETWORK TELENET - 
CHANNELS 2018-1546 - 

LINE DUP-0 - 
STATE ON 

Define executor specific parameters for local node CHCAGO. 

The TYPE parameter for the executor node defaults to 

ROUTING IV. 

DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 


Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 


DEFINE EXECUTOR 


NAME CHCAGO - 
NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 
each remote node when it receives an inbound connect request. 


DEFINE NODE 2 NAME BUFFLO 

DEFINE NODE 3 NAME SDIEGO 


Define parameters for line/circuit DMC-0 to node BUFFLO. 

DEFINE LINE DMC-0 PROTOCOL DDCMP POINT - 

STATE ON - 

DEFINE CIRCUIT DMC-0 STATE ON 


Define parameters for the outgoing DLM circuit X25-0UT to node 
SDIEGO (node SDIEGO is addressed as DTE 311444555666 to the 
X.25 network; subaddress 1 is defined on node SDIEGO to be a 
DECnet DLM subaddress). 


DEFINE CIRCUIT X25-0UT - 


NETWORK TELENET - 
NUMBER 3114445556661 - 
OWNER EXECUTOR - 
USAGE OUTGOING - 
STATE ON 
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The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 


Define transmitter-related logging parameter. 
DEFINE LOGGING MONITOR KNOWN EVENTS 


Define receiver-related logging parameters. 


5.3.62 


DEFINE LOGGING MONITOR STATE ON 


Node SDIEGO Database 

Use the following NCP commands to configure the node SDIEGO database. 


Set up the X.25 protocol module. 


DEFINE MODULE X25-PR0T0C0L - 

NETWORK TELENET PROFILE TELENET 

Define the line used to communicate with the X.25 network. 

DEFINE LINE DUP-0 NETWORK TELENET STATE ON 


Define the local DTE for node SDIEGO. 

DEFINE MODULE X25-PROTOCOL - 

DTE 311444555666 - 

NETWORK TELENET - 
CHANNELS 2490-2452 - 

LINE DUP-0 - 
STATE ON 

Define executor-specific parameters for local node SDIEGO. 
Note that the X.25 subaddress range is given as 1 to 5 so 
that this node can accept all X.25 calls with a subaddress 
from 1 to 5. Because CHCAGO is sending X.25 calls said does 
not intend to receive any, you need not specify the 
subaddress parameter for this DTE. The system manager must 
coordinate the subaddress values used to designate DECnet 
data link calls among the DECnet nodes. 




DEFINE EXECUTOR ADDRESS 3 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

SUBADDRESSES 1-5 - 

STATE ON 


Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 

DEFINE EXECUTOR NAME SDIEGO - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 
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Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 
each remote node when it receives an inbound connect request. 

DEFINE NODE 1 NAME CHCAGO 

DEFINE NODE 2 NAME BUFFLO 

Define parameters for the incoming DLM circuit X25-INC (to 
node CHCAGO). 

DEFINE CIRCUIT X25-INC NETWORK TELENET OWNER EXECUTOR - 

USAGE INCOMING - 
STATE ON 

The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 


Define transmitter-related logging parameters. 


DEFINE LOGGING MONITOR KNOWN EVENTS 


Define receiver-related logging parameters. 


DEFINE LOGGING MONITOR STATE ON 


5.3.7 X.25 Native Mode Network Example 

This example builds a database for a network configuration associating a local 
DTE with a packet switching data network (the United Kingdom PSDN called 
PSS) by a DUP line. The example builds server and object modules to handle 
incoming calls. 

Figure 5-7 An X.25 Native-Mode Network Configuration 


DTE 234123456789 
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Use the following NCP commands to configure the permanent database for 
the X.25 native-mode network. 


Set up the X.25 protocol module. 

DEFINE MODULE X25-PR0T0C0L - 

NETWORK PSS PROFILE PSS 
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j 

! Define the line used to communicate with the X.25 network. 

I 

DEFINE LINE DUP-0 NETWORK PSS STATE ON 

j 

! Define the local DTE. 

DEFINE MODULE X25-PR0T0C0L - 

DTE 234123456789 - 
NETWORK PSS - 
CHANNELS 2018-1546 - 
LINE DUP-0 - 
STATE ON 

! Define the destinations. 


DEFINE MODULE X25-SERVER - 

DESTINATION JOE - 
SUBADDRESS 1-10 - 
OBJECT OBJONE - 
PRIORITY 1 

DEFINE MODULE X25-SERVER - 

DESTINATION JIM - 
SUBADDRESS 11-15 - 
OBJECT OBJTWO - 
PRIORITY 2 

DEFINE MODULE X25-SERVER - 

DESTINATION DEFDEST - 
OBJECT DEFOBJ - 
PRIORITY 0 


Define the X.29 call handler. 


DEFINE MODULE X29-SERVER STATE ON 


Define the objects used for incoming calls. 
DEFINE OBJECT OBJONE - 

FILE OBJSTUP.COM - 
USER PSIUSER - 
PASSWORD PSIUSER 

DEFINE OBJECT OBJTWO - 

FILE OBJECTTWO.COM - 
USER JIM - 
PASSWORD JIM 

DEFINE OBJECT DEFOBJ - 

FILE LSTCHNCE.COM - 
USER NET - 
PASSWORD NET 


5.3.8 X.25 Multihost Mode Network Example 

The following example illustrates the NCP commands used to configure three 
VAX/VMS nodes connected by an Ethernet UNA line and circuit, with one 
node set up as an X.25 multihost connector node to the PSDN called PSS and 
the other two nodes set up as host nodes to use the connector node. 

In this example, node ROBIN, with VAX PSI multihost software installed, 
is configured as the connector node, and nodes THRUSH and LARK, each 
with VAX PSI Access software installed, are configured as host nodes that can 
communicate with the X.25 network through ROBIN. 
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Figure 5—8 An X.25 Multihost Mode Network Configuration 
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You must complete the following tasks in order to configure this network: 

• Build the Ethernet network. 

• Build the appropriate databases on ROBIN to configure this node as the 
X.25 connector node. 

• Configure THRUSH and LARK as host nodes capable of accessing the 
X.25 network through the connector node ROBIN. 


5.3.8.1 Building the Ethernet Network 

Use the following NCP commands to configure the node ROBIN database. 
Repeat the procedure to configure the databases for nodes THRUSH and 
LARK. 


Define executor-specific parameters for local node 
ROBIN. The TYPE parameter for the executor node defaults 
to ROUTING IV. 

DEFINE EXECUTOR ADDRESS 20 - 

BUFFER SIZE 576 - 

STATE ON 


Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 


DEFINE EXECUTOR NAME ROBIN - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remaining nodes. 

DEFINE NODE 21 NAME THRUSH 

DEFINE NODE 22 NAME LARK 
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Define parameters for line/circuit UNA-O. 

DEFINE LINE UNA-0 STATE ON 

DEFINE CIRCUIT UNA-0 STATE ON 

The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 


Define transmitter-related logging parameters. 
DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 
DEFINE LOGGING MONITOR STATE ON 


5.3.8.2 Configuring the X.25 Connector Node 

The following NCP commands build the X25-PROTOCOL and X25-SERVER 
databases for a multihost PSI node. Node ROBIN is configured as the VAX 
PSI multihost node connected to the PSDN named PSS. 


Set up the X.25 protocol module. 

DEFINE MODULE X25-PR0T0C0L NETWORK PUBLIC PROFILE PSS 

Define the line used to communicate with the X.25 network. 
DEFINE LINE DUP-0 NETWORK PUBLIC STATE ON 
Define the local DTE. 


DEFINE MODULE X25-PR0T0C0L - 

DTE 311111222333 - 
NETWORK PUBLIC - 
CHANNELS 2018-1546 - 
LINE DUP-0 - 
STATE ON 

Define host destinations for incoming calls. 


DEFINE MODULE X25-SERVER - 

DESTINATION THRUSH - 
SUBADDRESSES 1-10 - 
OBJECT 36 - 
NODE THRUSH 

DEFINE MODULE X25-SERVER - 

DESTINATION LARK - 
SUBADDRESSES 11-20 - 
OBJECT 36 - 
NODE LARK 
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5.3.8.3 Configuring the Host Nodes 

The NCP commands below build the X25-ACCESS and X25-SERVER 
databases on nodes THRUSH and LARK to allow both host nodes to access 
PSS through connector node ROBIN. 

Node THRUSH database 


Set up the X.25 access module. 


DEFINE MODULE X25-ACCESS - 

NETWORK PUBLIC - 
NODE ROBIN 


Define the destination on THRUSH. 


DEFINE MODULE X25-SERVER - 

DESTINATION JOE - 
SUBADDRESS 1-10 - 
OBJECT 0BJ0NE 


Define the X.29 call handler. 


DEFINE MODULE X29-SERVER STATE ON 


Define the destination objects for incoming calls. 


DEFINE OBJECT 0BJ0NE - 

FILE OBJSTUP.COM - 
USER PSIUSER - 
PASSWORD PSIUSER 


Node LARK database 


Set up the X.25 access module. 


DEFINE MODULE X25-ACCESS - 

NETWORK PUBLIC - 
NODE ROBIN 


Define the destination on LARK. 


DEFINE MODULE X25-SERVER - 

DESTINATION JOE - 
SUBADDRESS 11-20 - 
OBJECT OBJTWO 


! 

! Define the X.29 call handler. 

j 

DEFINE MODULE X29-SERVER STATE ON 

j 

! Define the destination object for incoming calls. 

i 


DEFINE OBJECT OBJTWO - 

FILE OBJTWO.COM - 
USER JIM - 
PASSWORD JIM 
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5.3.9 X.25 Multinetwork Example 

This example builds a database for a network configuration where a 
VAX/VMS system is connected to a PSDN (the United Kingdom PSDN 
called PSS) and also to a non-DIGITAL machine which behaves like an X.25 
DTE. The non-DIGITAL connection uses the profile ISO8208. VAX PSI is 
running in native mode. 

Figure 5-9 A Multinetwork Configuration 
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Use the following NCP commands to configure the permanent database for 
the multinetwork configuration. 


Set up the networks. The PSS connection will be called network PUBLIC 
and the other network will be called NONDEC (using the profile IS08208). 


DEFINE MODULE X25-PR0T0C0L - 

NETWORK PUBLIC - 
PROFILE PSS 

DEFINE MODULE X25-PR0T0C0L - 

NETWORK NONDEC - 
PROFILE IS08208 

Define the line used to connect to PSS. 


DEFINE LINE KMY-0 NETWORK PUBLIC STATE ON 


Define the line used to connect to the non-DIGITAL machine. 


DEFINE LINE DMF-0 - 

NETWORK NONDEC - 
INTERFACE DCE - 
STATE ON 


Define the DTE addresses. 
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DEFINE MODULE X25-PR0T0C0L - 

DTE 234212345678 - 
NETWORK PUBLIC - 
LINE KMY-0 - 
CHANNELS 1056-1024 
DEFINE MODULE X25-PROTOCOL - 

DTE 123456789012 - 
NETWORK NONDEC - 
LINE DMF-0 - 
CHANNELS 100-1 - 
INTERFACE DCE 

Define the destinations. The destination, JOE, receives calls 
from PUBLIC only. 


DEFINE MODULE X25-SERVER - 

DESTINATION JOE - 
SUBADDRESS 1-10 - 
NETWORK PUBLIC - 
OBJECT OBJONE - 
PRIORITY 1 

The destination, JIM, receives calls from either network. 

DEFINE MODULE X25-SERVER - 

DESTINATION JIM - 
SUBADDRESS 11-16 - 
OBJECT OBJTWO - 
PRIORITY 2 

The destination, DEFDEST, provides a general destination for calls 
that do not match the other destinations. 


DEFINE MODULE X25-SERVER - 

DESTINATION DEFDEST 
OBJECT DEFOBJ - 
PRIORITY 0 

Define the X.29 call handler. 


DEFINE MODULE X29-SERVER STATE ON 


Define the objects used for incoming calls. 
DEFINE OBJECT OBJONE - 

FILE OBJSTUP.COM - 
USER PSIUSER - 
PASSWORD PSIUSER 

DEFINE OBJECT OBJTWO - 

FILE OBJECTTWO.COM - 
USER JIM - 
PASSWORD JIM 

DEFINE OBJECT DEFOBJ - 

FILE LSTCHNCE.COM - 
USER NET - 
PASSWORD NET 


5.4 System Configuration Guidelines 

Proper network operation, particularly in a routing environment, requires 
that you properly configure the system software running on each node in the 
network. Memory and processor time are two principal resources that you 
need to define. 
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5.4.1 Normal Memory Requirements 

Most of the memory required by the network software is allocated from the 
VAX/VMS nonpaged dynamic memory pool. This pool is configured by 
setting the NPAGEDYN, IRPCOUNT, LRPCOUNT, and LRPSIZE system 
parameters. 

These SYSGEN parameters are set by the AUTOGEN facility when the 
operating system is first booted and do not normally require modification. If, 
however, you find that the SYSGEN parameters must be reset to properly 
tune the system, run SYS$SYSTEM:SYSGEN, as shown in the following 
example, and change the parameter values. 

$ RUN SYSISYSTEM:SYSGEN 
SYSGEN>USE CURRENT 
SY SGEN > SHOW/MAJ OR 


SYSGEN>SET NPAGEDYN number 
SYSGEN>SET IRPCOUNT number 
SYSGEN>SET LRPCOUNT number 
SYSGEN>SET LRPSIZE number 
SYSGEN > SHOW/MAJ OR 


SYSGEN>WRITE CURRENT 
SYSGEN>EXIT 

$ 


5.4.1.1 NPAGEDYN Parameter 

To increase the nonpaged dynamic pool space, calculate the value for the 
SYSGEN parameter NPAGEDYN using the following equation: 

number = current value + total driver value +a+b+c+d 

current value The current byte count without any version of DECnet- 

VAX installed (derived from the SYSGEN command SHOW 
/MAJOR). 

total driver value The total number of bytes required to load the driver plus 
NETDRIVER (see Table 5-3 for driver sizes). 

a The total number of bytes required for all lines used by 

DECnet-VAX. Use the following formula to determine the 
approximate space required. 

a = (number of lines) * (number of buffers) * (buffer size) 

The buffer size and the number of buffers are determined 
by the values you give to the executor BUFFER SIZE and 
individual line RECEIVE BUFFERS parameters. 

b The total number of bytes required for the DECnet-VAX 

data structure that handles logical links. Use the following 
equation to determine the approximate space required, 
b * 512 * number of links 

The number of links is determined by the value you give to 
the executor MAXIMUM LINKS parameter. 
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c The total number of bytes required for the DECnet data 

structure that handles circuits. Use the following equation to 
determine the approximate space required. 

c = 60 * number of circuits 

The number of circuits is the number of circuits you intend 
to use. 

d A multiple of the additional IRPCOUNT count. Use the 

following equation to determine this value. 

d = (new IRPCOUNT - current IRPCOUNT) * 200 

The new IRPCOUNT is computed as in Section 5.4.1.2; the 
current IRPCOUNT is the current count without any version 
of DECnet-VAX installed. 

Use the NCP SHOW EXECUTOR and SHOW CIRCUITS commands to 
display parameter values that you have set for the local node. 

The number of bytes required to load NETDRIVER and the individual drivers 
is given in Table 5-3. 


Table 5-3 Driver Sizes 


Driver Software 

Number of Bytes 

NETDRIVER 

14,500 

CNDRIVER (Cl) 

3,000 

NODRIVER (asynchronous) 

13,000 

XDDRIVER (DMP) 

9,800 

XEDRIVER (UNA) 

13,000 

XGDRIVER (DMF) 

15,000 

XMDRIVER (DMC) 

9,800 


5.4.1.2 IRPCOUNT Parameter 

With the SYSGEN command SET IRPCOUNT, increase the number of 
preallocated I/O request packets to reflect the increase of nonpaged dynamic 
pool space using the following formula. 

number - current value + number of buffers + maximum circuits + 2 

current value The current count without any version of DECnet-VAX 

installed. 

number of buffers The number of buffers that may be used by DECnet-VAX 
in peak periods (see Section 5.4.1.1). 

number of circuits The number of circuits that you intend to use. 


5.4.1.3 LRPCOUNT and LRPSIZE Parameters 

Calculate the value for the SYSGEN parameter LRPCOUNT according to the 
following formula: 

number of buffers = number of lines + number of receive buffers 

The number is the total number of receive buffers specified for all lines plus 
the total number of lines. 


The value for LRPSIZE should match that of the BUFFER SIZE parameter in 
the executor database. 
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Refer to the VAX/VMS System Generation Utility Reference Manual for a 
complete discussion of the System Generation Utility (SYSGEN). Note that 
the new settings for LRPCOUNT and LRPSIZE will not take effect until the 
next time the operating system is booted. 


5.4.2 Critical Routing Node Requirements 

For some critical routing nodes in large networks, it may be necessary to 
guarantee that user processes running on the node never interfere with the 
memory requirements of the network software. In this case, you may want to 
configure the system for worst-case use of the nonpaged dynamic pool. 

The use of nonpaged pool is controlled by the quota values that you specify 
for each user when you create the user's authorization record. For worst-case 
configuration, the sum of the quotas of all the simultaneously active processes 
must provide the required free pool for the network software. 

To configure a system for such a worst case, adhere to the following four 
rules: 

• The sum of the ASTLM (asynchronous system trap limit), BIOLM 
(buffered I/O limit), DIOLM (direct I/O limit), and TQELM (timer queue 
limit) quotas for each process must be added to the IRPCOUNT parameter. 

• The FILLM (file and logical link limit) quota for each process must be 
doubled and added to the IRPCOUNT parameter. 

• The ENQLM (enqueue limit) quota for each process must be doubled and 
added to the IRPCOUNT parameter. ENQLM is the number of locks each 
process can own. 

• The BYTLM (buffered I/O byte count limit) quota for each process must 
be added to the NPAGEDYN parameter. 

Given these guidelines, the result of the calculation below should be less than 
the total free pool after the network has initialized: 

USERPROCESSES * (((ASTLM + BIOLM + DIOLM + TQELM + (FILLM * 2)) * 96) + BYTLM) 

For example, if for a critical routing node you also want to provide for 16 
users' processes, the calculation might be 

16 * (((10 + 6 + 6 + 5 + (8 * 2)) * 96) + 4096) = 16 * 8224 = 131584 bytes 

This calculation indicates that there should be at least 131,584 bytes 
of nonpaged dynamic pool remaining after the network has initialized. 
However, because it is extremely unlikely that all users will require their 
quota of pool at the same time, then, except for a worst-case configuration, 
the quotas and pool could be configured minimally so that no one user's 
quota would completely deplete the free pool. Use the SHOW MEMORY 
operator command or the dynamically updated POOL display for the Monitor 
Utility to configure the nonpaged dynamic memory pool for normal use. 

The consequences of running almost or completely out of pool are fairly 
obvious to system users: System performance will be very sluggish; processes 
will continually enter the MWAIT scheduling state while they wait for an 
available free pool; and the free pool SHOW MEMORY display will indicate 
almost none. 
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If the lack of pool causes the network software on the node to be unable 
to allocate a buffer fast enough to receive data from a communications 
line, the line may be considered unusable by another node in the network. 
When this happens, the network will attempt to adaptively reconfigure 
itself, thereby resulting in network traffic consisting of configuration update 
messages. If the node with pool problems should be close to failing, without 
failing completely, it may alternate between working and not working, 
thereby causing the network to repeatedly reconfigure itself. Ultimately, these 
reconfigurations will degrade the performance of the entire network. 


5.4.3 CPU Time Requirements 

Proper system configuration to provide adequate processor time for the 
network software is somewhat more straightforward. Most of the procedures 
that control network routing are located in NETDRIVER. Because most of 
NETDRIVER runs at elevated interrupt priority level (IPL), normal user 
programs cannot preempt its execution. However, user-written drivers and 
privileged programs running at elevated IPL can affect the proper operation 
of NETDRIVER. 

Writing a Device Driver for VAX/VMS provides guidelines for elevated IPL 
execution programming. In general, a program should run at elevated IPL 
only as long as necessary to synchronize correctly with other processes and 
devices. In particular, running at IPL IPL$_SYNCH for more than a few 
hundred milliseconds or running at any IPL at or above IPL$_MAILBOX 
for more than a few hundred milliseconds may adversely affect the network 
software. The effect of improper elevated IPL programming on the whole 
network is the same as having insufficient free nonpaged dynamic pool. 

The procedure that handles the automatic network reconfiguration for a 
network node is contained in the NETACP process. Therefore, for proper 
network operation, the NETACP process must also be assured of sufficient 
processor time. It runs at base priority of 9, which is well above the 
recommended base priority of 4 for normal users. However, real-time 
processes running at priorities 10 through 31 can preempt the execution 
of NETACP. 

Just as for user-written drivers, the programming of real-time processes must 
account for the needs of the network software and other system software. 

A rule of thumb for real-time processes is that they should not normally 
preempt the execution of NETACP for more than a few hundred milliseconds 
at a time, and they should never preempt its execution for more than 5 to 10 
seconds. This restriction allows NETACP sufficient processor time to run its 
routing algorithms properly. 

If NETACP is unable to perform all of its functions, the effects on the whole 
network will be the same as having insufficient free pool or incorrect elevated 
IPL programming. If the above guidelines cannot be met for a particular 
real-time application, the application should probably not be used on a node 
that is also doing network routing. 

The NETACP process, like all system processes, can be swapped and 
paged. However, because its base priority is 9, it will be one of the last 
processes swapped when it is running and swapping becomes necessary. 
Also, NETACP receives high priority for paged disk I/O requests. Again, 
improper considerations for the disk I/O needs of NETACP can adversely 
affect the network as a whole. If the NETACP process continually enters the 
PFW or COMO scheduling state, it is probably not receiving sufficient priority 
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for paging or swapping; other real-time or system programs should probably 
be modified to relieve the problem. 


5.4.4 UNIBUS Adapter Map Register Considerations 

The UNIBUS adapter on VAX processors provides a mechanism called 
UNIBUS map registers (UMRs) that allows UNIBUS peripherals to access 
VAX main memory. These map registers are required because the UNIBUS 
allows only 18 bits of address space while the VAX processors provide 24 
or 30 bits (depending on processor type). The 18 bits of address space are 
divided into 496 pages of 512 bytes each. Therefore, there are 496 map 
registers that allow up to 496 pages of memory to be mapped for direct 
memory access (DMA) by UNIBUS devices. 

Because UNIBUS map registers are a limited resource needed for correct 
operation of the network software, some consideration should be given to 
their use. 

VAX/VMS provides a service for device drivers to allocate and deallocate 
map registers. Most drivers allocate map registers only for the time it takes 
for the device to perform a transfer, after which they deallocate them for use 
by another I/O request to the same device or by other drivers for different 
devices. This type of allocation is referred to as dynamic allocation. 

Other drivers, however, permanently allocate map registers all the time the 
system is running. This is either because certain memory tables must be 
accessible to the device (TS11, DMC11, and DMP11) all the time the device 
is initialized or because of certain throughput requirements of the device (1 
megabaud DMC11/DMR11, DMP11, DEUNA, and LPA11). This type of 
allocation is referred to as permanent allocation. 

If a device driver process attempts to allocate UMRs and there are not enough 
free to satisfy the allocation, the driver process is put into a FIFO wait queue 
to wait for UMRs to become available. 

The following list presents the UNIBUS map register requirements of the 
various supported UNIBUS devices. 

• The TS11 driver permanently allocates a maximum of three map registers 
in its command table for each TS11 on the UNIBUS when it initializes. 
The TS11 supports one DMA I/O request at a time, and because an I/O 
can be up to 65,536 bytes in size, the TS11 driver requires a maximum of 
128 map registers that can be allocated dynamically. 

• The RL02, RK06, RK07, and RX02 disk drives support one DMA I/O 
request at a time. Because the maximum I/O request size can be 65,536 
bytes, these drivers require a maximum of 128 map registers that can be 
allocated dynamically. 

• The LPA11-K laboratory data acquisition device driver can be configured 
to permanently or dynamically allocate up to 496 map registers. The 
SYSGEN parameter LAMAPREGS allows you to specify how many map 
registers are to be permanently allocated; if this parameter is 0, map 
registers will be dynamically allocated as needed when the device is used 
for I/O. 

• The DMC11/DMR11 driver permanently allocates a maximum of three 
map registers for its base table when it initializes. It also permanently 
allocates enough map registers for all of its receive buffers, which are set 
with the RECEIVE BUFFERS line parameter and BUFFER SIZE executor 
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parameter. However, if more than seven receive buffers are specified per 
line, only seven sets of map registers per line will be allocated. 

The DMC11/DMR11 driver supports one DMA transmit at a time and 
because each transmit can be a maximum of 16,383 bytes in size, the 
DMC11/DMR11 driver requires a maximum of 32 map registers that can 
be allocated dynamically. 

• The DMP11 driver allocates map registers in the same way that the 
DMC11/DMR11 driver does with the exception that the DMP11 driver, 
which does not have a base table, requires three fewer map registers. 

• The DEUNA device driver assigns eight receive buffers with a length of 
1500 bytes per buffer. Enough map registers are permanently allocated for 
all receive buffers. 

The following example details how one might determine whether sufficient 
map registers will be available. Assume the example system consists of a 
VAX-11/780 with a single UNIBUS adapter, two RK07 disk drives on a 
single controller, a TS11 tape drive, and three DMRlls. The BUFFER SIZE 
executor parameter is set to 576 and each line has its RECEIVE BUFFERS 
parameter set to 4. Because each buffer can potentially cover three pages 
(two pages to contain the 576-byte buffer and one page for an offset page) 
and because the VAX/VMS map register allocator always allocates an extra 
invalid map register for protection, each buffer will require four map registers. 


Device 

Permanent Map Registers 

TS11 

DMR11 (3) 

Three permanent map registers would be required for the TS1 1. 

Fifty-seven map registers would be required for the three 
DMRlls. (Each DMR permanently allocates 19 map registers; 
three UMRs for the base table and four UMRs for each of the 
four receive buffers. 


Therefore, 496 minus 60, or 436 map registers are available for dynamic use 
by all devices. 

Because the TS11 and RK07s can each be using 128 map registers, there will 
always be at least 436 minus 256, or 180 map registers available to map 
DMR11 transmit buffers. This amount is more than sufficient as the DMRlls 
will each have only one transmit of 576 bytes outstanding at a time, which 
will require a maximum of 3 times 4, or 12 map registers. 

In general, because VAX/VMS has dynamic map register allocation and 
waiting when UNIBUS map registers run out, they are not a resource 
problem. However, if a system has a large number of DMC11/DMR11, 
DMP11, and DEUNA devices, it is prudent to calculate map register use to 
ensure that the configuration works. 
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5.4.5 Permanent Database Considerations in VAXclusters 

The permanent configuration database, usually resident on disk, consists of a 
number of files. These files are listed in Table 5-4. 


Table 5-4 Permanent Configuration Database Files 


File Name 

Usage 

SYS$SYSTEM:NETNODE—REMOTE. DAT 

Remote node 

SYS$SYSTEM:NETNODE_LOCAL.DAT 

Executor and loop node 

SYS$SYSTEM:NETLINE.DAT 

Line 

SYS$SYSTEM:NETLOGING.DAT 

Logging 

SYS$SYSTEM:NETOBJECT.DAT 

Object 

SYS$SYSTEM:NETCIRC.DAT 

Circuit 

SYS$SYSTEM:NETX25.DAT 

X.25 module 

SYS$SYSTEM:NETX29.DAT 

X.29 module 

SYS$SYSTEM:NETCONF.DAT 

Configurator module 


In a homogeneous VAXcluster, it may be desirable to allow some of these files 
to be shared by members of the VAXcluster; shared files should be moved to 
SYS$COMMON:[SYSEXE] and files that are not to be shared should reside 
in SYS$SPECIFIC:[SYSEXE] (where they are normally created). Neither 
NETNODE_LOCAL.DAT nor NETX25.DAT should be shared as they contain 
executor information that is unique for each node in a VAXcluster. Other 
files such as NETLINE.DAT and NETCIRC.DAT should not be shared if 
the communications hardware configurations within the VAXcluster are not 
identical on every node. 

As an example, if the permanent object database is identical on every node in 
a VAXcluster, it can be shared by using the following steps: 

1 Rename (or move) the permanent object database on one node to the 
common system root, for example: 

$ RENAME SYS$SPECIFIC:[SYSEXE]NETOBJECT.DAT - 
_$ SYSICOMMON:[SYSEXE]NETOBJECT.DAT 

or 

$ COPY SYS$SPECIFIC:[SYSEXE]NETOBJECT.DAT - 
_$ SYSICOMMON:[SYSEXE]NETOBJECT.DAT 

2 Delete (or rename) the permanent object database from the private system 
root on each node in the VAXcluster, for example: 

$ DELETE SYSISPECIFIC:[SYSEXE]NETOBJECT.DAT;* 

or 

$ RENAME SYSlSPECIFIC:[SYSEXE]NETOBJECT.DAT;* - 
_$ SYSISPECIFIC:[SYSEXE]NETOBJECT.OLD;* 

The files SYS$SYSTEM:NETNODE.DAT and SYS$SYSTEM:NETNODE_ 
OLD.DAT are obsolete versions of the permanent node database that may be 
deleted. 
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6 Installation of a Network 


This chapter describes how to start DECnet-VAX and how to install and start 
VAX PSI. 


6.1 Installing a DECnet-VAX Key 

If you have purchased a license for either a DECnet-VAX full function kit 
or a DECnet-VAX end node kit, you must install the key for the license. 

The procedure for installing the appropriate license key is described in the 
DECnet-VAX Key Installation Guide, which is distributed with the key. 

The DECnet-VAX end node kit allows the node to be configured only as an 
end node. The DECnet-VAX full function kit allows the node on which it has 
been installed to be configured as either a routing node or an end node. To 
upgrade an end node license to a full function license, install the key for the 
full function kit. 


6.2 Bringing Up Your Network Node Using STARTNET.COM 

After you satisfy the prerequisites for establishing a network and define the 
necessary parameters in the configuration database (see Chapter 5), you are 
ready to bring up your DECnet-VAX node. To do so, you must have defined 
the local node (using the DEFINE EXECUTOR command) in the permanent 
database. This information is the minimum requirement for the initial control 
of the operational state of the node. 

After you build the permanent database using either NCP or the 
NETCONFIG.COM interactive configuration procedure (see Chapter 5), 
issue the following command to bring up your network: 

$ <QSYS$MANAGER: STARTNET. COM 

This command starts NCP and NML, and configures the volatile database 
with the parameters that you have defined in the permanent database. This 
procedure also turns on the local node and all lines and circuits connected to 
it. In addition, STARTNET.COM starts the network command terminal ACP 
by executing SYS$MANAGER:RTTLOAD.COM. At this point, the local node 
is ready for network operations with itself and with adjacent nodes. 

DECnet-VAX uses OPCOM to display certain network-related messages on 
the network operator's console. When you turn on the local node, OPCOM 
will display the following message: 

Opcom, hh:mm:88:cc, SYSTEM Acct= 

Opcom, DECnet starting 

Once you have brought up your DECnet-VAX node, you use NCP commands 
to control the operational states of network components. You can control 
both local components and remote executions of NCP commands. This 
control allows you to dynamically reconfigure your network to control the use 
of the network and its resources. Use the NCP commands CLEAR and SET 
for the volatile database to control the network. 
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Parameters in the permanent database define network components each time 
you use the word ALL with the SET command. Typically, you will use the 
SET "component" ALL command if you choose not to use STARTNET.COM 
to bring up the network. Section 6.5 discusses how you can shut down your 
network in an orderly manner. 

Note that if you are going to run VAX PSI, you must install the VAX PSI 
software before invoking STARTNET.COM. This also applies to VAX PSI 
Access software. 


6.3 Bringing Up Your VAX PSI DTE 

Bringing up VAX PSI DTE is similar to bringing up a node on the DECnet- 
VAX network. First, install VAX PSI, following the procedure described 
in the VAX PSI Installation Procedures. Make sure you configure VAX PSI 
in multihost mode (instead of native mode) if you are building a DECnet 
network that allows some or all of its nodes to access the PSDNs connected. 
The multihost installation will set up the commands necessary to bring up 
the connector node (the node connected to the PSDNs) as a DTE. (Section 5.3 
includes examples of both native mode and multihost mode configurations.) 

Invoking the STARTNET.COM procedure will bring up both DECnet-VAX 
and VAX PSI software. Once you are satisfied that VAX PSI is installed 
properly, you can use VAX PSI to communicate with a remote DTE over a 
packet switching data network (PSDN). 

Note that if you make changes to your PSI system while it is running and you 
wish to include these changes in your PSI system the next time the system is 
started, you must also make similar changes to the permanent database using 
NCP commands (DEFINE and PURGE). 


6.4 Testing the Installation with UETP Test Procedure 

To ensure that the DECnet-VAX installation is successful, you can use the 
User Environment Test Package (UETP) to test DECnet. The test procedure is 
described in the Guide to VAX/VMS Software Installation. 


6.5 Shutting Down Your DECnet—VAX Node 

Bringing down your operating system will automatically bring down your 
DECnet-VAX node as well. The next time you reboot the operating system, 
your network will come up automatically if SYSTARTUP.COM invokes 
STARTNET.COM (see Section 6.2). However, if the network is running and 
you want to shut down your network node in an orderly manner or otherwise 
restrict its use, you can use NCP to control the operational state of the local 
node. NCP offers three options for shutting down the executor node. 

• To shut down your local node without destroying active logical links, use 
the command 

NCP>SET EXECUTOR STATE SHUT 

This command closes the node in an orderly fashion; new links are not 
allowed, and existing links are not destroyed. When all logical links are 
disconnected, this command turns off the node, and NCP logs an event 
message. 
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Once the last link terminates and is disconnected, the executor node in 
the SHUT state enters the OFF state. This action occurs whether or not 
the node is currently in use for route-through traffic. Consequently, the 
communication path between nodes using the local node for route-through 
may be broken. 

• Instead of shutting down your local node, you can restrict network 
operations on that node. This restriction does not affect current logical 
link activity; however, no new inbound logical links can be created unless 
they originate locally or unless a process with the OPER privilege confirms 
them. Use the following command to restrict local node operations: 

NCP>SET EXECUTOR STATE RESTRICTED 

• To shut down the local node regardless of current logical link activity, use 
the command 

NCP>SET EXECUTOR STATE OFF 

This state allows no new logical links to be created, terminates existing 
links, and stops route-through traffic. 

Note: Programs that have declared names or object numbers and that are 
started independently of DECnet-VAX should be programmed to 
terminate when their mailboxes receive a MSG$__NETSHUT message. 
This message appears when the node is shutting down. 

Whenever the local node's state goes to OFF, DECnet-VAX uses the OPCOM 
facility to display the following message on the console: 

Opcom, hh:mm:as:cc, SYSTEM Acct= 

Opcom, DECnet shutting down 

Table 6-1 summarizes local node states and basic network operation 
restrictions for them. These operations include network routing, confirming 
inbound connections from a remote node, and initiating outbound 
connections to a remote node. 

If your network configuration includes VAX PSI, shutting down a DECnet- 
VAX node will also shut down VAX PSI and clear the PSI volatile database. 
Bringing up the DECnet-VAX node subsequently will restart VAX PSI and 
recreate the volatile database from the permanent database. 


Table 6-1 Local Node States and Network Operations 


State 

Route-Through 

Traffic 

Connect Confirm 

Operations 

Connect Initiate 

Operations 

ON 

Unrestricted 

Unrestricted 

Unrestricted 

RESTRICTED 

Unrestricted 

Unrestricted only if the partner node 
is the local node or if the confirming 
process has the OPER privilege 

Unrestricted 

SHUT 

Unrestricted 

Unrestricted only if the confirming 
process has the OPER privilege 

Unrestricted only if the 
initiating process has the 
OPER privilege 

OFF 

Restricted 

Restricted 

Restricted 
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NCP provides several kinds of tests to help you determine whether the 
network is operating properly. Specifically, these tests let you exercise 
network software and hardware by sending data through various network 
components and then returning that data to its source. After you have started 
DECnet-VAX software, you may want to run some of these tests. 

In general, problems that you encounter with the DECnet-VAX network will 
probably arise from misconfigured VAX/VMS and DECnet parameters that 
can easily be fixed using SYSGEN or NCP. DIGITAL supplies variations of 
these tests to exercise separate layers of the network. User-written processes 
or DECnet-supplied processes may also initiate the tests. 

DECnet-VAX tests fall into two categories: node-level loopback tests and 
circuit-level loopback tests. Use node-level tests to evaluate the operation 
of logical links, routing, and other network-related software. Use circuit- 
level tests to evaluate the operation of circuits. It is suggested that you use 
node-level tests first; then, if necessary, use circuit-level tests. This chapter 
describes these variations as they relate to DECnet loopback capabilities and 
the NCP command LOOP, and provides a practical approach to their use. 
Note that LOOP commands cannot be used on asynchronous lines or circuits. 

VAX PSI provides various ways to analyze software and hardware operation 
and to diagnose problems in PSI operations. Use line-level loopback tests 
to evaluate the operation of the X.25 physical lines and communications 
hardware. VAX PSI provides an additional facility for the KMS11 and KMV11 
line interfaces, allowing you to dump the microcode to a specified file for 
analysis. This chapter describes these VAX PSI test facilities and how to use 
them. For additional details about the VAX PSI test facilities, refer to the VAX 
PSI Problem Solving Guide. 


7.1 Node-Level Tests 

Node-level loopback tests will test the logical link capabilities of a node by 
exchanging test data between DECnet processes on two different nodes or 
between DECnet processes on the same node. These tests consist of two 
types: 

• Loopback tests for logical link operation regardless of the circuit 

• Loopback tests for operation over a specified circuit 

The second test sends test messages over a specified circuit associated with a 
loop node name (see Section 7.1.2). This test directs test messages regardless 
of the Routing layer function. 

Both types of node-level loopback tests allow you to test the functions of your 
DECnet-VAX software. To test various aspects of this software, you may 
want to perform a series of operations, as described below. 

1 In the first test, loop information to a remote loopback mirror process 
using a remote loopback test. This tests all local and remote network 
software up to the DNA user layer on the remote node. 
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2 If the first test fails, use a loop node name and loop information to the 
local node and to a remote node. The loop node name allows you to 
direct traffic over a specified circuit, which tests local and remote Routing 
software. 

3 If the second test fails, set the circuit's line to "controller loopback" and 
repeat step 2. 

Regardless of the type of test you choose, use the NCP command LOOP 
NODE to send test messages. This NCP function uses a cooperating process 
called the Loopback Mirror to facilitate the transmission and reception of test 
messages. When you issue this command, you have the option of controlling 
the type of binary information (MIXED, ONES, ZEROS); the number of 
blocks of information, which ranges from 1 to 65,535; and the length in 
bytes of each block to be looped, which also ranges from 1 to 65,535. (It is 
recommended that you use a maximum block length of 4096 bytes to reduce 
the system load.) Refer to the VAX/VMS Network Control Program Reference 
Manual for the complete syntax of the LOOP NODE command. 

If your message returns with an error, the test stops and NCP prints a 
message that indicates a test failure, specifies the reason for the failure, and 
provides a count of the messages that were not returned. For a summary of 
NCP error messages, refer to the VAX/VMS System Messages and Recovery 
Procedures Reference Manual. 

In the example below, the test attempted to send 10 messages, each 50 bytes 
long. The first two messages were sent successfully, and an error occurred on 
the third. 

ncp>loop node boston count 10 

'/.NCP-I-NMLRSP, listener response- line communication error 
Messages not looped = 8 


7.1.1 Remote Loopback Test 

Use the LOOP NODE command to test for a logical link connection between 
two nodes. When using this command, you must identify the node to which 
you want to loop test messages. Figure 7-1 illustrates a remote loopback test. 

For this test, you first turn the selected remote node line and circuit to the ON 
state to allow for logical link activity. Then use the LOOP NODE command. 
For example, the set of commands below tests both local and remote DECnet 
software on nodes BOSTON and TRNTO. 

NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>L00P NODE TRNTO COUNT 10 


7.1.2 Local and Remote Loopback Tests Using a Loop Node Name 

If the remote loopback test failed, then use the LOOP NODE command with 
a loop node name to test a logical link path over a specified circuit. You 
can loop test messages either over a logical link path and circuit within the 
local node or between two different nodes with a loop node/bold specified 
for the circuit to be used. Use the latter method first in order to test remote 
Routing layer software. In each case, use the SET NODE command with 
the CIRCUIT parameter to establish a loop node name. For example, the 
following command establishes circuit DMC-0 as the circuit over which loop 
testing will take place: 
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7.1.2.1 


Figure 7-1 Remote Loopback Test 


NCP Commands: 

NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>LOOP NODE TRNTO COUNT 10 


BOSTON (executor) TRNTO 



NCP 








Loopback 

Mirror 



NML 




_J 



(logical link) 




ZK-555-81 


NCP>SET NODE TESTER CIRCUIT DMC-0 

No other parameters are valid for loop nodes. This circuit must be turned on 
when performing these tests. 

Note that you cannot assign two loop node names to the same circuit. For 
example, once you establish TESTER as the loop node name for circuit 
DMC-0, you must issue a CLEAR NODE TESTER CIRCUIT command before 
assigning another loop node name to DMC-0. 

When a logical link connection request is made to the loop node name, all 
subsequent logical link traffic will be directed over the associated circuit. 

The destination of the traffic is whatever node address is associated with the 
loop node name. The loop node name is necessary because, under normal 
operation, DECnet Routing software selects which path to use when routing 
information. The loop node name overrides the routing function so that 
information can be routed over a specific circuit. To remove the association 
of the loop node name with a circuit, use the CLEAR NODE CIRCUIT or 
CLEAR NODE ALL command, as in the following command: 

NCP>CLEAR NODE TESTER CIRCUIT 

A loop node name specified with the SET NODE CIRCUIT command may 
be used for any network traffic (for example, COPY requests or application 
program traffic). The loopback node name appears as a valid node name in 
the network for all purposes. 


Local-to-Remote Testing 

To test a logical link path over a circuit between the local node and a remote 
node, you must specify a loop node name for the given circuit and issue the 
LOOP NODE command. Figure 7-2 illustrates a local-to-remote loopback test 
using a loop node name. 
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Figure 7-2 Local-to-Remote Loopback Test Using a Loop Node 
Name 


NCP Commands: 

NCP>SET LINE DMC-0 STATE ON 
NCP>SET NODE TESTER CIRCUIT DMC-0 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>LOOP NODE TESTER COUNT 10 


BOSTON (loop node TESTER) Remote Node 
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For this test, you first turn on the line and set a loop node name for the 
given circuit to the remote node. Next, turn on the circuit. Finally, issue the 
LOOP NODE command using the loop node name, as shown in the following 
example: 

NCP>SET LINE DMC-0 STATE ON 
NCP>SET NODE TESTER CIRCUIT DMC-0 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>L00P NODE TESTER COUNT 10 

This set of commands tests both local and remote Routing layer software 
operation. The test messages are looped over the loopback circuit. Because 
the test actually tests the operation of the Routing layer on the remote node, 
the message may not come back on the circuit over which it was sent. 


7.1.2.2 Local-to-Local Testing 

If the local-to-remote test fails, try a local loopback test with the local node to 
test local Routing layer software exclusively. To test a logical link path over a 
specified line on the local node, specify a loop node name and set the device 
controller to loopback mode. Figure 7-3 illustrates a local-to-local loopback 
test using a loop node name. 

For this test, you first turn off the line, set the controller to loopback mode, 
and turn on the line and circuit. Finally, set a loop node name for the given 
line and issue the LOOP NODE command using the loop node name. The 
set of commands below tests the Routing layer software and the controller on 
the local node. 

NCP>SET LINE DMC-0 STATE OFF 
NCP>SET LINE DMC-0 CONTROLLER LOOPBACK 
NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>SET NODE TESTER CIRCUIT DMC-0 
NCP>L00P NODE TESTER COUNT 10 LENGTH 32 
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Figure 7-3 Local-to-Local Loopback Test Using a Loop Node 
Name 


NCP Commands: 

NCP> SET LINE DMC-0 STATE OFF 

NCP> SET LINE DMC-0 CONTROLLER LOOPBACK 

NCP> SET LINE DMC-0 STATE ON 

NCP>SET CIRCUIT DMC-0 STATE ON 

NCP>SET NODE TESTER CIRCUIT DMC-0 

NCP> LOOP NODE TESTER COUNT 10 LENGTH 32 


BOSTON (loop node TESTER) 
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Because the device is set to loopback mode, the test messages are looped over 
the circuit and back to the local node. If this test fails, try a local loopback 
test to test local DECnet software. 

Note: Because of restrictions in the operation of the DMC controller, you must 
use a block length of fewer than 50 bytes for controller loopback tests. 


7.1.3 Local Loopback Test 

If the loopback tests described in Section 7.1.2.2 should fail, then use either 
the LOOP NODE command with the local node-id or the LOOP EXECUTOR 
command to test local DECnet software. This type of test uses DECnet- 
VAX software to loop messages to the loopback mirror on the local node. 
Figure 7-4 illustrates a local loopback test. 

For this test, you simply issue the following command at the local node: 

NCP>L00P EXECUTOR COUNT 10 

This test evaluates the local DECnet software using an internal logical link 
path. If this test succeeds and the other node-level tests fail, then try the 
circuit-level tests. If these tests fail, the executor's default nonprivileged 
DECnet account is probably set up incorrectly. 
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Figure 7-4 Local Loopback Test 


NCP Commands: 

NCP>LOOP EXECUTOR COUNT 10 


BOSTON (executor) 


NCP 




NML 



(logical link) 


Loopback 

Mirror 


7.2 Circuit-Level Tests 

Circuit-level loopback tests will test a DECnet circuit by looping test data 
through a hardware loopback device on the circuit, either through a modem 
(or loopback connector) or through a remote node. The tests that use a 
hardware loopback device are referred to as controller loopback tests; the 
tests that use a loopback connector or a modem are referred to as circuit 
loopback tests; the tests that use the software capabilities of the system are 
referred to as software loopback tests. 

You may want to perform a series of operations to test various aspects of a 
circuit. These operations are described below. 

1 In the first test, perform a software loopback test to another node to 
determine whether the circuit is operational up to the remote circuit unit 
and controller. 

2 If the first test fails, set the controller to loopback mode and use a 
controller loopback test to determine whether the controller works. 

3 If the second test succeeds, then attach a modem (or loopback connector) 
to the controller and use a circuit loopback test to determine whether the 
unit is functional. 


Regardless of the test type, you must use the NCP command LOOP CIRCUIT 
to perform a circuit-level loopback test. When you issue this command, you 
have the option of controlling the type of binary information (MIXED, ONES, 
ZEROS); the number of blocks of information, which ranges from 1 to 65,535; 
and the length in bytes of each block to be looped, which also ranges from 1 
to 65,535. (It is recommended that you use a maximum block length of 4096 
bytes.) For the complete syntax of the LOOP CIRCUIT command, refer to the 
VAX/VMS Network Control Program Reference Manual. 
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If your message returns with an error, the test stops and NCP prints a 
message indicating a test failure, the reason for the failure, and a count of 
the messages that were not returned. For a summary of NCP error messages, 
refer to the VAX/VMS System Messages and Recovery Procedures Reference 
Manual. In the example below, the test attempted to send 10 messages, each 
50 bytes long. The first two messages were sent successfully, and an error 
occurred on the third. 

NCP>SET LINE DMC-0 CONTROLLER NORMAL STATE ON 
NCP>L00P CIRCUIT DMC-0 COUNT 10 

V.NCP-1 -NMLRSP, listener response- line protocol error 
Messages not looped = 8 


7.2.1 Software Loopback Test 

Use the LOOP CIRCUIT command to perform a software loopback test of 
a circuit connected to the local node. This type of test uses DECnet-VAX 
software to loop through the circuit to circuit service software in the adjacent 
node and back to the local node. Figure 7-5 illustrates a software loopback 
test to test whether the circuit is operational up to the remote unit and 
controller on the adjacent node. 

Figure 7-5 Software Loopback Test 


NCP Commands: 

NCP>SET LINE DMC-0 STATE OFF 
NCP>SET LINE DMC-0 CONTROLLER NORMAL 
NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>LOOP CIRCUIT DMC-0 COUNT 10 


BOSTON (executor) Remote Node 
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In the first step of this test, you turn the line off. Next, you set the controller 
to its normal operational mode and put the line and the circuit in the ON 
state. Finally, you issue the LOOP CIRCUIT command. This sequence is 
shown below. 

NCP>SET LINE DMC-0 STATE OFF 
NCP>SET LINE DMC-0 CONTROLLER NORMAL 
NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>L00P CIRCUIT DMC-0 COUNT 10 

This set of commands tests the circuit DMC-0 up to the adjacent node. If this 
test fails, try a circuit loopback test to verify that the circuit is functional. 
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7.2.2 Controller Loopback Test 

Use the LOOP CIRCUIT command to perform a controller loopback test of 
a physical line on the local node while the controller is in loopback mode. 
This type of test verifies whether or not the circuit up to the controller and 
the controller itself are functional. Figure 7-6 illustrates a controller loopback 
test. 

Figure 7-6 Controller Loopback Testing 


NCP Commands: 

NCP>SET LINE DMC-0 STATE OFF 

NCP>SET LINE DMC-0 CONTROLLER LOOPBACK 

NCP>SET LINE DMC-0 STATE ON 

NCP>SET CIRCUIT DMC-0 STATE ON 

NCP> LOOP CIRCUIT DMC-0 COUNT 10 LENGTH 32 


BOSTON (executor) 



For this test, you first turn the line off. Next, you set the controller to 
loopback mode and put the line and circuit in the ON state. Finally, you 
issue the LOOP CIRCUIT command. For example: 

NCP>SET LINE DMC-0 STATE OFF 

NCP>SET LINE DMC-0 CONTROLLER LOOPBACK 

NCP>SET LINE DMC-0 STATE ON 

NCP>SET CIRCUIT DMC-0 STATE ON 

NCP>L00P CIRCUIT DMC-0 COUNT 10 LENGTH 32 

This set of commands tests the circuit up to the controller for physical line 
DMC-0 connected to the local node by circuit DMC-0. 

Note: Because of restrictions in the operation of the DMC controller, you must 
use a block length of fewer than 50 bytes for controller loopback tests. 
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7.2.3 Circuit-Level Loopback Testing 

Circuit-level loopback testing is also supported for Ethernet circuits. One 
major difference between loopback testing on point-to-point and multipoint 
circuits (DMCs and DMPs) and on an Ethernet circuit is that the former 
requires two separate processors (one at each end), but the latter requires 
only one processor. In Ethernet circuit loopback testing, it is the target node's 
Ethernet interface rather than its processor that loops the messages. 

In Ethernet circuit-level loopback testing (as in the case of point-to-point 
circuit loopback testing), network management accesses the Data Link layer 
directly, thus bypassing intermediate layers. One advantage of the Ethernet 
loopback test is that it can be performed concurrently with other DECnet 
operations on the circuit. 


7.2.3.1 Testing with the PHYSICAL ADDRESS and NODE Parameters 

To be tested, an Ethernet circuit must be in the ON state and the SERVICE 
parameter must be set to ENABLED. Note that, by default, the SERVICE 
parameter is set to DISABLED for Ethernet circuits. As indicated in Chapter 2, 
DECnet supports the UNA, which provides for multiaccess connections 
between many nodes on the same Ethernet circuit. In the example below, the 
command identifies the circuit device UNA and the controller number 0 for 
an Ethernet circuit. 

NCP>SET CIRCUIT UNA-0 STATE ON SERVICE ENABLED 

The UNA is used to loop messages on the Ethernet circuit. If desired, it can 
be used to loop messages to itself in order to test its own state. To do this, 
enter the following commands: 

NCP>SET LINE UNA-0 STATE OFF 

NCP>SET LINE UNA-0 CONTROLLER LOOPBACK STATE ON 
NCP>SET NODE TEST CIRCUIT UNA-0 
NCP>LOOP NODE TEST 

In this case you were able to test the status of the UNA in controller loopback, 
but not the capacity of the node to transmit and receive messages. For 
more information on the node's capacity to send and receive messages, see 
Section 7.1.2.2. 

More typical cases of loopback testing of Ethernet circuits involve looping 
messages to remote systems over the Ethernet; this tests the capability of both 
the local and the remote UNAs to send and receive messages. In those cases, 
you are required to supply such information as the Ethernet physical address 
or the node name or address of the circuit at the remote node that you wish 
to test. 

Nodes on Ethernet circuits are identified by unique Ethernet addresses. 

An Ethernet address is 48 bits in length and is represented by six pairs of 
hexadecimal digits (6 bytes), separated by hyphens (for example, AA-01-23- 
45-67-89). For more detail on Ethernet addresses, see Section 3.3.4. 

Each UNA on the Ethernet circuit has a hardware address (in read-only 
memory) that has been assigned to it by the manufacturer. Typically, DECnet 
will set an Ethernet physical address for the UNA, thereby replacing the 
hardware address as the address to which the UNA currently responds. The 
UNA's physical address will continue to be the address to which it responds, 
unless it is reset to the hardware address value (for example, if the Ethernet 
circuit is set to OFF). 
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It is helpful to know the Ethernet physical address of the UNA on the remote 
node that you wish to test. Since this is not always possible, it is a good 
practice if you plan to perform loopback tests to include the hardware address 
of each of the UNAs on your Ethernet circuit in the permanent database, 
thus ensuring that the address will be retrievable from the volatile database. 
You can then use the node-id in the LOOP command. When node-id is 
specified, network management software retrieves the hardware address from 
the volatile database and attempts to transmit the loop message to the remote 
UNA by alternately using the hardware address and the physical address that 
DECnet would normally use. 

The following example contains an Ethernet physical address: 

NCP>L00P CIRCUIT UNA-0 PHYSICAL ADDRESS AA-00-04-00-FF-04 

Since in this case you know the physical address of the remote node that you 
wish to test, you merely include the PHYSICAL ADDRESS parameter with its 
value. If, however, that physical address had changed (for example, if it had 
been reset to the hardware address value), the loopback would have failed. 
You would have received the following message: 

7.NCP-I-NMLRSP, listener response line protocol error 
Messages not looped = 1 

If you also know the name or address of the remote node, you could test 
the UNA on that node even though its Ethernet physical address may 
have changed. The Ethernet hardware address of the node to be tested 
must already have been entered in the database on the executor node. If 
the hardware address is included in the volatile database, and you test by 
supplying the node name or address, the loop test will be attempted by the 
network management software to both the hardware address and the DECnet 
address. 

An example of a loopback test that specifies the NODE parameter is the 
following: 

NCP>L00P CIRCUIT UNA-0 NODE TEST 

Assume that TEST'S physical address, which was AA-00-04-00-F7-04, is 
changed. Thus any attempt to test TEST using the old physical address 
would not succeed. If, however, TEST'S hardware address (which was 
AA-00-03-00-01-31) is included in the volatile database on the executor 
node, the loopback test with the NODE parameter in its specification would 
succeed. 

In the above example, you could alternatively supply the node address value 
(such as 226) for the NODE parameter. For example, if you know the node-id 
but not the name of the node, you could specify 

NCP>L00P CIRCUIT UNA-0 NODE 226 

In this case, the node address is used to construct the DECnet physical 
address and the Ethernet hardware address (assuming that it is included 
in the volatile database) is used to access the circuit on the remote node 
and complete the loopback test. Thus it is important to enter the hardware 
address in the volatile database. 

If you want to examine the Ethernet hardware address of your own UNA 
(in this case UNA-0), you can use the NCP command SHOW LINE 
CHARACTERISTICS. When you enter the command 

NCP>SH0W LINE UNA-0 CHARACTERISTICS 
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you will receive a display such as the following: 

Line Volatile Characteristics as of 15-APR-1986 15:33:25 
Line = UNA-0 


Receive buffers 
Controller 
Protocol 
Service timer 
Hardware address 
Buffer size 


= 0 

= normal 
= Ethernet 
= 4000 

= AA-00-03-00-12-00 
= 1498 


7.2.3.2 Loopback Assistance 


DECnet supports the use of an assistant physical address and an assistant 
node to aid you in interrogating a remote node. To use this feature, you 
specify either the ASSISTANT PHYSICAL ADDRESS parameter or the 
ASSISTANT NODE parameter as an additional parameter to the LOOP 
CIRCUIT command. 

You can use the "assistant" in three distinct ways. First, you can use it to 
assist you in receiving loop messages from a remote node. Second, you can 
use it in transmitting loop messages to a remote node. Third, you can use it 
in both transmitting messages to and receiving messages from a remote node. 

There are various reasons why you might choose one form of assistance over 
another. For example, it is possible that the target node to which you wish 
to transmit a message is located at a point where the signals are too weak to 
send a message. In this case, you could request assistance in transmitting the 
message to the target node. Similarly, you may be able to transmit messages 
to the target node, but not be able to receive messages from it. In such a case 
you can send a message directly to the target node and request an "assistant" 
to aid you in receiving a message from the target node. When you encounter 
difficulties in both sending and receiving messages, you can request an 
assistant node to help you to both transmit messages to and receive messages 
from the target node. 

The commands below illustrate the use of the ASSISTANT PHYSICAL 
ADDRESS and ASSISTANT NODE parameters. 

NCP>L00P CIRCUIT UNA-0 PHYSICAL ADDRESS AA-00-04-00-18-04- 
_ ASSISTANT PHYSICAL ADDRESS AA-00-04-00-15-04 

NCP>L00P CIRCUIT UNA-0 NODE LOON ASSISTANT NODE THRUSH 

In the first command, you are requesting the node described by the Ethernet 
physical address AA-00-04-00-15-04 to assist you in testing the node 
described by the Ethernet physical address AA-00-04-00-18-04. In the 
second command, you are requesting the node THRUSH to assist you in 
testing node LOON. 

If you specify either the ASSISTANT PHYSICAL ADDRESS or ASSISTANT 
NODE parameter and you do not specify the HELP parameter, you will 
receive FULL assistance; that is, you will be assisted both in receiving and 
transmitting loop messages. Note that in the above examples, because the 
ASSISTANT PHYSICAL ADDRESS and ASSISTANT NODE parameters were 
specified without the HELP parameter, the default is FULL assistance. 

If you wish to use an assistant node only to receive messages from the remote 
node, you could issue the following command: 

NCP>L00P CIRCUIT UNA-0 NODE LOON ASSISTANT NODE THRUSH HELP RECEIVE 
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In this example you are requesting the node THRUSH to assist you in 
receiving messages from node LOON. When you wish to be assisted only in 
sending or transmitting loop messages, you could issue a command such as 
the following: 

NCP>L00P CIRCUIT UNA-0 NODE LOON ASSISTANT NODE 21 HELP TRANSMIT 

Note that in this case the ASSISTANT NODE parameter contains the node 
address, rather than the name of the node as in the previous example. In 
each of the last two examples, the HELP parameter was included to specify 
the type of assistance desired. 


7.3 X.25 Line-Level Loopback Tests 

There are three types of line-level loopback tests that you can use to test an 
X.25 physical line: 

• External loopback tests that loop data back through the modem 

• Internal loopback tests that loop data back through the device 

• External loopback tests that loop data back through a loopback device on 
the line 

You may want to perform the series of operations below to test various 
aspects of the physical line. 

1 First, using the loop switch on the modem, perform an external loopback 
test through the modem. This test checks the logic of the device 
transmitter and receiver, the line driver, the modem cable, and part of 
the modem. If this test is successful and you still have errors, contact your 
network manager. 

2 If the first test fails, perform an internal loopback to test only the logic of 
the device transmitter and receiver. 

3 If the second test succeeds, attach a hardware loopback device to the 
modem cable. Then perform an external loopback to test the logic of the 
device transmitter and receiver, the line driver, and the modem cable. 

Regardless of the test type, use the NCP command SET LINE to specify the 
type of loopback test and the NCP command LOOP LINE to initiate the 
line-level loopback test. 

Specify values for two parameters of the SET LINE command, as follows: 


Internal Loopback External Loopback 

STATE SERVICE STATE SERVICE 

CONTROLLER LOOPBACK CONTROLLER NORMAL 


Note that the line state must be set to OFF before the CONTROLLER 
parameter can be changed. 

To initiate a test, use the LOOP LINE command with the same line identifier 
you specified with the SET LINE command. For example, the commands 
below initiate an external loopback test for the line DUP-0: 

NCP>SET LINE DUP-0 ... STATE SERVICE CONTROLLER NORMAL 
NCP>L00P LINE DUP-0 ... 

Associate parameters with the LOOP LINE command to control the type of 
test information and the size and number of blocks sent during testing. 
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Use the COUNT and LENGTH parameters to specify the number of blocks 
sent over the line during a test and the length (in bytes) of each block sent. 
The command line below sends 2000 blocks 100 bytes long over the line. 

NCP>L00P LINE DUP-0 COUNT 2000 LENGTH 100 ... 

Specify decimal integers in the range 1 to 65,535 for both these parameters. 
Note that this test will take approximately 5 minutes, as calculated below. 

2000 * (100+4)*8 

- seconds = 5 minutes 

5000 

A DUP runs at 5000 bps when looped back. 

Use the WITH parameter to specify the type of binary information sent during 
loopback testing. You can specify three types of binary information: 

ONES All binary Is 

ZEROES All binary 0s 

MIXED A random combination of Is and Os 

For example, the command below sends 2000 blocks 100 bytes long, each 
containing all binary Is, over the line: 

NCP>L00P LINE DUP-0 COUNT 2000 LENGTH 100 WITH ONES 

If you omit the WITH parameter, a combination of Is and Os (MIXED) is 
sent. If you omit the COUNT and LENGTH parameters, one block of 128 
bytes is sent. For example, the command below sends one block of 128 bytes, 
containing mixed binary information, over the line: 

NCP>L00P LINE DUP-0 

Further details on loopback testing are given in the VAX PSI Problem Solving 
Guide. 


7.4 Dumping KMS11 and KMV11 Microcode 

This section describes how to dump the KMS11 or KMV11 microcode to a file 
and how to analyze the dump file. The KMS11 and KMV11 are synchronous 
line devices that interpret the X.25 level 2 protocol. They are supported by 
VAX PSI (see the table of DECnet circuit and line devices in the VAX/VMS 
Network Control Program Reference Manual). 

Use the MICROCODE DUMP parameter of the NCP command SET LINE to 
dump the microcode of the specified device to the file indicated. By default, 
the output file takes the format below, where filename is the file that you 
specify. 

filename.DMP 

For example, the command below dumps the microcode of the file 
BARRY.DMP in your current default directory: 

NCP>SET LINE KMX-0-0 MICROCODE DUMP BARRY 

Use the DUMP parameter only if you believe there is an error in the 
microcode of the KMX, KMY, or KMV. 

The KMS/KMV dump analyzer can be used to process the dump file. 

For a description of the dump analyzer, refer to the VAX PSI Problem Solving 
Guide. 
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Performing Network User Operations 


DECnet-VAX allows you to perform a variety of operations over the network. 
For example: 

• Retrieving information about the status of the nodes in your network 

• Establishing communication with a remote DECnet node through the 
heterogeneous command terminal facility 

• Accessing files on remote nodes 

• Performing task-to-task operations 

This chapter describes each of these operations. The primary focus of this 
chapter, however, is on the use of task-to-task communication in network 
operations. 

For VAX PSI user operations, refer to the VAX PSI documentation set. 


8.1 Retrieving Network Status Information 

Before you perform a specific type of operation over the network, you may 
want to check the status or availability of a particular node or nodes in your 
network. To retrieve such information, you can use the DCL command 
SHOW NETWORK. 

Note that the SHOW NETWORK command can be used to retrieve 
information about your network only if your local node is a routing node. 

If your local node is a nonrouting (end) node, you will not receive any 
network information; instead, you will be directed to a designated routing 
node. 

The SHOW NETWORK command displays the availability of the local node 
as a member of the network and the addresses and names of all nodes that 
are currently accessible to the local node. 

The SHOW NETWORK command also displays link and cost relationships 
between the local node and other nodes in the network. It displays the 
current network in terms of five characteristics: node, links, cost, hops, and 
next hop to node. 


Node 

Identifies each available node in the network by its node 
address and node name. 

Links 

Shows the number of logical links between the local 
node and each available remote node. 

Cost 

Shows the total line cost of the path to a remote node. 
The cost for each line in the network is assigned by the 
system manager. 

Hops 

Shows the number of intervening nodes plus the target 
node. 
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Next hop to node Shows the outgoing physical line used to reach the 

remote node. (The local node is identified by the term 
LOCAL.) 

When you enter the SHOW NETWORK command, you will receive a display 
on your terminal similar in format to the following: 

VAX/VMS Network Status for local node 2.161 ARAKIS on 15-APR-1986 
The next hop to nearest area router is node 2.62 ZEUS. 


Node 

Links 

Cost 

Hops 

Next Hop 

to 

Node 

2.161 ARAKIS 

0 

0 

0 

Local 

-> 

2.161 ARAKIS 

2.1 RAEL 

0 

8 

1 

UNA-0 

-> 

2.1 RAEL 

2.2 PANGEA 

0 

8 

1 

UNA-0 

-> 

2.2 PANGEA 

2.3 TWDEE 

0 

10 

2 

UNA-0 

-> 

2.63 AURORA 

2.4 TWDUM 

0 

8 

1 

UNA-0 

-> 

2.4 TWDUM 

2.11 NEONV 

0 

8 

1 

UNA-0 

-> 

2.11 NEONV 

2.63 AURORA 

0 

8 

1 

UNA-0 

-> 

2.63 AURORA 


Total of 7 nodes. 


If your local node is an end node, and you enter the SHOW NETWORK 
command, you will receive the following message on your terminal: 

This is a nonrouting node, and does not have any network 
information. The designated router for node ARAKIS is 
node 2.62 ZEUS. 

If you enter the SHOW NETWORK command, but the network is unavailable 
at that time, you will receive the following display: 

Network unavailable 

For more detailed information on the DCL command SHOW NETWORK, see 
the description in the VAX/VMS DCL Dictionary . 


8.2 Establishing Communication with a Remote Node 

DECnet-VAX supports a command terminal facility that permits a single user 
to establish communication with a remote node and to use the facilities of 
that system while physically connected to the local node. By means of this 
link, you can temporarily become a local user of the remote node and thereby 
perform functions that the remote node allows its local users to perform. 

Note that in addition to communicating with remote VAX/VMS nodes, you 
can also communicate with non-VAX/VMS nodes that support the DNA 
heterogeneous remote command terminal protocol facility. Consult the 
Software Product Description for non-VMS operating systems and their 
DECnet implementations. 

If you wish to use the command terminal facility to establish communication 
with a remote node, enter the DCL command SET HOST. The format for this 
command is 

$ SET HOST nodename 

The nodename is a 1- to 6-character name or number specifying the remote 
node at which you want to log in. The SET HOST command does not 
recognize the area prefix in a node number. Therefore, to specify by number 
a node in another area, you must convert the node number to its decimal 
equivalent (as described in Section 3.7.2). 
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The remote node system will prompt for a username and password. If the 
information you supply is valid, you will be logged in to the remote node. To 
return control to your local node, type LOGOUT. 

You will receive the following message at your terminal: 

'/.REM-S-END, Control returned to node _nodename: : 

This message indicates that control has been returned to your local node. 

The only special control character used for remote command terminal 
operations is CTRL/Y. Except for CTRL/Y, all control characters are handled 
as if they were issued at the local node. 

Repeated, rapid pressing of CTRL/Y will generate a prompt asking if the 
remote connection should be broken. If you answer "Yes" to the prompt, 
control will return to the local node. This technique is useful if for some 
reason you cannot return to the local node normally. 

The following command sequence illustrates the operation of remote 
command terminals for our network topology example. The name of the 
local node is BOSTON. 

$ SET HOST TRNTO 
Username: SMITH 
Password: 

Welcome to VAX/VMS Version 4.0 on node TRNTO 


$ LOGOUT 

SMITH logged out at 8-APR-1986 12:31:55:49 
‘/.REM-S-END, Control returned to node .BOSTON:: 

$ 


Once you are logged in at a remote node, you can use the SET HOST 
command to establish communication with another node. After logging in to 
node TRNTO, you could type SET HOST DENVER. 

You would again be prompted for a username and password. If you then 
supply a valid username and password, you will be logged in at node 
DENVER. 

Note that when you log out at node DENVER, control is returned to node 
TRNTO. You must log out from node TRNTO to return to your local node, 
BOSTON. 

For more detailed information on the SET HOST command, see the 
description in the VAX/VMS DCL Dictionary. 


8.3 Accessing Files on Remote Nodes 

DECnet-VAX allows you to access files on remote nodes in your network as 
though these files were on your local node. You can use the DECnet-VAX 
facilities to access remote files by means of DCL commands and command 
procedures, higher-level language programs, and MACRO programs using 
VAX RMS or VAX/VMS system services. 
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8.3.1 Using DCL Commands and Command Procedures 

Most DCL commands used to perform file operations at a local node can 
also be used to perform these operations on remote nodes. For example, you 
can use the same DCL commands to obtain directory listings, manipulate 
files, and execute command procedures on remote nodes. You need only 
prefix a node name followed by two colons to the standard VAX/VMS file 
specification to access the remote file. 

For example: 

$ TYPE TRNTO::WORKS:[DOE]LOGIN.COM 

In this example, the TYPE command requests that the file LOGIN.COM in 
the directory DOE at the remote node TRNTO be displayed on your local 
terminal. 

As with DCL, remote file accessing by higher-level languages is accomplished 
in a way that is transparent to the user. All that you need to specify is the 
name of the remote node containing the file or files that you wish to access. 
Like DCL, higher-level language programs also employ the VAX RMS services 
to perform file access operations. 

Other examples of the use of DCL commands to access remote files can be 
found in the VAX/VMS DCL Concepts Manual. Command descriptions in that 
document also include restrictions that apply to individual commands and 
command qualifiers used over the network. Unless otherwise stated, you can 
assume that a particular DCL command is supported for network operations. 


8.3.2 Using Higher-Level Language Programs 

You can use various higher-level languages to write programs that access 
remote files. Regardless of the programming language used, you access 
remote files exactly as you would access local files. 

For example, assume you want to design a FORTRAN program to transfer 
files from a local node to a remote node. Also assume that the two nodes 
are identified by the logical names SRC and DST, respectively. You can use 
two DCL commands to define the logical names for the files involved in the 
transfer, by entering the following commands: 

$ DEFINE SRC TRNTO::USER:[STOCKROOM.PAPER]INVENTORY.DAT 
$ DEFINE DST BOSTON::LPAO: 

Once you have made the logical name assignments, the FORTRAN program 
can open the files by way of those logical names. You can use the following 
FORTRAN open calls: 

OPEN (UNIT=1.NAME=•SRC'.TYPE='OLD'.ACCESS*'SEQUENTIAL', 

FORM*'FORMATTED') 

OPEN (UNIT*2,NAME*'DST',TYPE*'NEW',ACCESS*'SEQUENTIAL'. 

FORM*'FORMATTED',CARRIAGECONTROL*'LIST', 

RECORDTYPE*'VARIABLE') 

This FORTRAN program uses standard I/O statements to transfer records 
from one file to another. In this example, the access mode is sequential. 

Examples of complete higher-level language programs designed to access 
remote files are included in the appropriate sections of each VAX language's 
programming manuals. 
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8.3.3 Using MACRO Programs 

The VAX/VMS system provides a programming interface for remote file 
accessing using VAX MACRO. The MACRO programs can use VAX Record 
Management Services (RMS) calls or VAX/VMS system service calls. 

This section describes how RMS can be used to access remote files. The 
VAX/VMS system services, which can also be used for remote file accessing, 
are described more thoroughly in Section 8.5.4. 

For remote file processing, RMS integrates the network software necessary to 
translate standard RMS calls, which provides a transparent user interface to 
the network. 

Using the RMS facilities, you can perform remote file-handling operations on 
entire files or access individual records, through programmed RMS service 
calls in a VAX/VMS MACRO application. All you need to do is supply the 
name of the remote node in your file specification. 

As in the FORTRAN example above, you can use DCL commands to make 
logical name assignments to the source and destination files that you wish to 
manipulate. 

$ DEFINE SRC TRNTO::USER:[STOCKROOM.PAPER]INVENTORY.DAT 
$ DEFINE DST BOSTON::TEMP:[ARCHIVE]INVENTORY.DAT 

Before you can open either the source (SRC) or destination (DST) files with 
the RMS $OPEN statement, however, you must allocate the appropriate file 
access blocks (FABs) and record access blocks (RABs) in your program. To do 
this you can use the RMS structures shown below. 


SRC.FAB: 


$FAB 

FAC=GET,- 
F0P=SQ0.- 
FNM=SRC 

$RAB 

FAB=SRC_FAB,- 
RAC=SEQ,- 


These statements define the source file FAB and RAB control blocks. You 
must also define the destination file FAB and RAB control blocks. 


DST.FAB 

$FAB FAC=PUT,- 
F0P=SQ0.- 
FNM=DST.- 
0RG=SEQ,- 
RFM=VAR,- 
RAT=CR 

DST.RAB 

$RAB FAB=DST_FAB,- 
RAC=SEQ,- 
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After defining the source and destination FABs and RABs, you can now open 
the files for remote file processing. Note that if your program accesses files 
sequentially, you can specify the sequential-only (SQO) option of the file 
options (FOP) field of the FAB. Specifying FOP=SQO enables RMS and the 
remote File Access Listener (FAL) to enter into file-transfer mode, which 
significantly increases file-transfer performance. 

Examples of complete MACRO programs using RMS to access remote files 
are contained in the Guide to VAX/VMS File Applications . Examples in this 
document also illustrate the network-specific features provided by VAX RMS. 

RMS fields and options that must be specified for DECnet-VAX applications 
are described in the VAX Record Management Services Reference Manual of 
the VAX/VMS System Routines Reference Volume. This manual also describes 
restrictions that apply to using RMS over the network. See Chapter 9 for 
a list of restrictions on VAX/VMS operations involving other systems in a 
heterogeneous network. 

Note that DECnet-VAX does not support the use of RMS for operations on a 
remote magnetic tape volume. 


8.4 Performing Task-to-Task Operations 

Task-to-task communication, a feature common to all DECnet 
implementations, allows two programs running under the same or different 
operating systems to communicate with each other regardless of the 
programming languages used. For example, a FORTRAN program running 
on the VAX/VMS system at node BOSTON could exchange messages with 
a MACRO program running on the RSX-11M system at node DALLAS. 
Although these programs use different programming languages and run 
under different operating systems, the DECnet software translates system- 
dependent language calls into a common set of network protocol messages. 
Note that in the context of task-to-task communication, the terms "task" and 
"program" are used synonymously. 


8.4.1 Transparent and Nontransparent Task-to-Task Communication 

DECnet-VAX supports both transparent and nontransparent task-to-task 
communication. Transparent communication provides all the basic functions 
necessary for a DCL command procedure or a user program (written in either 
VAX/VMS MACRO or in a higher-level language) to communicate with other 
command procedures or user programs over the network. Nontransparent 
communication allows the MACRO programmer to use more network-specific 
functions. 

A simple analogy illustrates the differences between these two forms of 
communication. Transparent communication is similar to device-independent 
I/O in VAX/VMS in which you move data with little concern for the way the 
operation is accomplished. Likewise, transparent communication allows you 
to move data across the network without necessarily knowing that you are 
using DECnet software. Nontransparent communication, on the other hand, 
is analogous to device-dependent I/O, in that you are interested in specific 
characteristics of the device that you want to access. A nontransparent task, 
in turn, can use network-specific features to monitor the communication 
process. 


8-6 






Performing Network User Operations 


8.4.1.1 Transparent Communication 

Transparent communication provides the basic functions necessary for a 
task to communicate with another task over the network. These functions 
include the initiation and completion of a logical link connection, the orderly 
exchange of messages between both tasks, and the controlled termination of 
the communication process. To perform these functions, you can program 
your transparent task in any of the higher-level languages supported over the 
network, in VAX MACRO (using RMS service calls or system service calls) or 
even using DCL commands. 

One way to view transparent communication is to look at the programming 
required to develop such an application. Transparent access provides the 
minimum functions necessary to communicate over the network using 
standard I/O operations. When accessing the network transparently, you 
use no DECnet-specific calls to perform these functions; rather, you use 
standard RMS I/O service calls or the normal I/O statements provided by 
the applicable language to access a sequential record-oriented device. (The 
remote task is modeled as two VAX/VMS mailboxes in which two processes 
can perform read and write operations.) You can also use system service calls 
to perform transparent communication, as described in Section 8.5. 


8.4.1.2 Nontransparent Communication 

Nontransparent communication provides the same basic functions as 
transparent communication plus additional system service and I/O functions 
supported by DECnet-VAX. In particular, a nontransparent task can create 
and use a VAX/VMS mailbox to receive information that would otherwise 
remain inaccessible to a transparent task. Thus you can make use of network- 
specific features such as optional user data on connects and disconnects, and 
interrupt messages. Also, certain nontransparent tasks that have a mailbox 
can receive and process multiple inbound connection requests. 

Note that on a VAXcluster node, nontransparent tasks that can receive 
multiple inbound connection requests should not use the cluster alias node 
address for outgoing connections, and should not be enabled to receive 
incoming connections directed to the cluster alias node. Incoming links 
directed to a cluster alias node address can be assigned to any of the nodes 
in the cluster that accept that alias node address, without knowledge of the 
nodes on which a declared task may be running (see Section 2.6.2). 

In general, nontransparent tasks can use a mailbox to receive information 
about particular network operations. Mailbox messages are of four types: 

• Messages that result from the use of certain system service calls (including 
optional user data carried on logical link creation or termination) 

• Interrupt messages 

• Logical link status messages 

• Network system messages 

Nontransparent functions that indirectly cause mailbox messages to be 
placed in the receiver's mailbox include calls for initiating and completing 
logical links, and calls for terminating links. Figure 8-1 illustrates the use of 
mailboxes by nontransparent tasks. 

A list of mailbox messages and their meanings is given in the VAX/VMS 
System Services Reference Manual. 
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Figure 8-1 Mailbox Messages 



| Mailbox I | Mailbox | 


L 



Synchronous Disconnect (opt. user data) 


Disconnect Abort (opt. user data) 


Z3C 


DECnet-VAX Software 


J 


MSGS_DISCON 

MSGS_ABORT 


Network Status Notifications: 


MSGS_EXIT 

MSGS_PATH LOST 

MSGS_PROTOCOL 

MSGS_TIMEOUT 

MSGS_THIRDPARTY 

MSGS_NETSHUT 


ZK-840-82 



A nontransparent task can also receive network status notifications in the 
mailbox. These notifications apply to physical and logical link conditions over 
the network. For example, DECnet-VAX software can notify a nontransparent 
task of the following conditions: 

• Third-party disconnections 

• Network software- and hardware-related problems 

• Processes exiting before I/O completion 

• Connection request timeouts 


Regardless of whether you are performing a transparent or nontransparent 
task-to-task operation, you must use a task specification string to identify 
the remote task with which you wish to communicate. 
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8.4.2 Task Specification Strings in Task-to-Task Applications 

A task specification string is a quoted string that identifies the remote task to 
which you attempt a logical link connection. 

To establish a logical link connection with a remote task addressed as object 
type 0, use either of the following forms of task specification string: 

• "TASK=taskname" 

• "(Maskname" 

Note that "0" and "TASK" are equivalent. The taskname can be from 1 to 12 
characters. 

If the remote node is a VAX/VMS system, the taskname represents the 
file name of a command procedure to be executed at the remote node. (If 
the remote node is not a VAX/VMS system, the maximum length of the 
taskname may be different.) The command procedure can complete the 
logical link itself (using a DCL OPEN command), or it can include a DCL 
RUN command to execute a program that completes the logical link. 

The examples that follow illustrate two uses of the task specification string. 
The specification below identifies the task TEST2 by using the TASK= form 
for specifying remote tasks. The second example is the same as the first, 
except that access control information is provided and the alternative 0= form 
for specifying a task is used. 

BOSTON::»TASK=TEST2» 

BOSTON"SMITH JOHN"::»0=TEST2" 

In this example, TEST2 refers to SYS$LOGIN:TEST2.COM at the remote 
VAX/VMS node. Note that only the file name component of the command 
file specification is used in the task name string. 


8.4.3 Functions Required for Performing Task-to-Task Operations 

Several functions are necessary for performing a task-to-task operation. The 
number of functions will, of course, depend on whether you intend to access 
the network transparently or nontransparently. 

Even a transparent task-to-task application requires a minimum number 
of operations to initiate and complete a logical link connection, to 
exchange messages, and to terminate the logical link. These operations 
are actually a subset of a larger group of functions defined for nontransparent 
communication. The entire set of functions is as follows: 

• Initiating a logical link connection 

— Requesting a logical link to a remote task 1 

— Declaring a network name and processing multiple connection requests 

• Completing a logical link connection 

— Rejecting a logical link connection request 
— Accepting a logical link connection request 1 


l 


Minimum subset for transparent task-to-task communication. 
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• Exchanging messages 

— Sending and receiving data messages 1 

— Sending and receiving interrupt messages 

• Terminating a logical link 

— Synchronously disconnecting the logical link 

— Aborting the logical link 1 

Nontransparent tasks can use any or all of these functions to extend the basic 
capabilities offered under transparent communication. 


8.4.3.1 Initiating a Logical Link Connection 

Regardless of whether you access the network transparently or 
nontransparently, you must establish a communication link to the remote 
node on which the target task runs before any message exchange can take 
place. You establish the link by issuing a source task call that requests a 
logical link connection. (The source task is the task that initiates a logical 
link connection request; the target task is the task with which you want to 
communicate). 

The interaction between the source task and the target task that takes place 
before the logical link is established is called a handshaking sequence. Upon 
receiving a call that requests a logical link connection, the local DECnet-VAX 
node initiates a handshaking sequence with the target task. The following 
information is supplied in a connection request: 

• An I/O channel. The I/O channel serves as the path over which messages 
are sent and received by the source program. 

• The identification of the target node. Every node in a network has an 
identifier that distinguishes it from all other nodes in the network. 
Transparent communication uses a task specification string to indicate 
the name of the target node. Nontransparent communication requires a 
user-generated data structure called the network connect block (NCB), 
which includes a task specification string. 

• An object type descriptor. 

• Access control information (optional). 

• Optional user data. Nontransparent tasks have the option of sending up 
to 16 bytes of data to the target program (see the information below on 
NCBs). 

It is important to be aware that once you issue a call that uses either a task 
specification string or an NCB, you access the network and, by definition, 
DECnet-VAX software. 


1 Minimum subset for transparent task-to-task communication. 
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8.4.3.2 Completing the Logical Link Connection 

As part of the handshaking sequence, the target task completes the logical 
link connection in two steps. First, the DECnet software at the remote node 
processes the inbound logical link connection request. Second, the target 
task either accepts or rejects the link. These steps are performed differently, 
depending on whether the target task uses transparent or nontransparent I/O. 

When a logical link request is received, a procedure called NETSERVER.COM 
is executed, which in turn invokes the image NETSERVER.EXE. This program 
works in conjunction with the network ACP (NETACP) and uses DCL to 
invoke the image or command procedure defined for the requested object (the 
specified task for object 0 or FAL for object 17). 

When the logical link is terminated, the "object" program (for example, FAL) 
also terminates. However, the process is not deleted. Instead, control is 
returned to NETSERVER.EXE, which communicates with NETACP to inquire 
for another incoming logical link request. This inquiry process continues until 
NETSERVER encounters a timeout condition (the default is 5 minutes). 

The time that NETSERVER waits for another logical link request can be 
specified by the system manager. The logical name NETSERVER$TIMEOUT, 
when defined, determines the amount of time NETSERVER will wait before 
reaching the timeout condition. Note that the equivalence name must be in 
the standard VAX/VMS delta time format. 

In the following discussion, it is assumed that the remote node is a VAX/VMS 
system. If the remote node on which your target task runs is not a VAX/VMS 
system, you should refer to the DECnet documentation for that system. 

Completing the Connection Transparently 

If the target task is transparent, the DECnet software at the remote node 
checks the access control information supplied in the connection request call. 

Before you access the remote node, the system manager must have created the 
appropriate account in the UAF (refer to the information on access control). In 
addition, the command procedure file (taskname.COM) for starting the remote 
task must exist in the directory associated with the account identified by the 
access control information. For a description of the command procedure 
taskname.COM, see Section 8.7.1, which contains examples of command 
procedures designed for task-to-task communication. 

Command procedures for objects existing in the OBJECT database (which is 
created using NCP commands) are located in the SYS$SYSTEM directory. 

The DIGITAL-supplied FAL.COM procedure is an example of such a 
command procedure. 

Completing the Connection Nontransparently 

If the target task is nontransparent, then one of several things may occur. 

If the task has not declared itself a network task (and is therefore eligible 
to accept only one connection request at a time), then the DECnet software 
at the remote node performs the access checking procedure. After it starts, 
the target task retrieves the connection information by translating the logical 
name SYS$NET using the $TRNLNM system service call (see Section 8.6). 

If the target task declares itself as an active network task, then 
DECnet-VAX software places all connection requests addressed to the task 
in the mailbox associated with the channel being used. The first message 
in the mailbox is the NCB from the original connection request that started 
the task. This message appears in the mailbox after channel assignment and 
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name declaration occur. Once the task declares a network name or number, 
subsequent inbound connection requests are not checked by the remote node 
to verify access control. (Note that if the task is started without being part of 
a DECnet operation, access control is never checked.) Section 8.6 describes 
in more detail the nontransparent process of completing the logical link 
connection. 

After examining the incoming connection request, the target task either 
accepts or rejects the request, and optionally can send 1 to 16 bytes of data 
back to the source task at the same time that it responds to the logical link 
connection request. Furthermore, a library routine, LIB$ASN_WTH_MBX, 
which assigns a channel and associates a unique mailbox, can be used when 
accepting the connection if no optional data is returned. 


8.4.3.3 Exchanging Messages 

You access the network transparently or nontransparently, DECnet-VAX 
sends data messages over a logical link in response to a set of send and 
receive calls issued by the source and target tasks. For higher-level language 
tasks, use standard READ and WRITE statements to send and receive data 
messages. (In Example 8-2, the two FORTRAN tasks use read and write 
statements to exchange information. The equivalent RMS service calls are 
$GET and $PUT.) 

After DECnet-VAX creates a logical link, the two tasks are ready to exchange 
messages. This exchange can take place only if the two tasks "cooperate" in 
the transmission process. In other words, for each message sent by a task, the 
receiving task must issue a corresponding call to receive the message. Also, 
you must decide which task will disconnect the link. In addition, if the tasks 
are nontransparent, they must agree on whether or not the optional data will 
be passed. In the context of an established logical link, the task sending a 
message is the transmitter and the task receiving it is the receiver. 

DECnet-VAX distinguishes between two types of messages: data messages 
and mailbox messages. Data messages are the normal mode of information 
exchange for both transparent and nontransparent communication. Mailbox 
messages such as interrupt messages, messages resulting from some DECnet 
operation (including optional user data), and network status notifications, can 
be used only in nontransparent communication. 

Nontransparent communication frequently involves using a mailbox to obtain 
network-specific information. A task may receive three types of messages in 
its mailbox: 

• Messages that DECnet generates when the task initiates certain network 
operations. A VAX/VMS task issues system service calls to initiate these 
operations. 

— When one task requests a logical link connection, a notification 
message (and optional user data) may be placed in the mailbox of 
the target task. 

— When a target task accepts or rejects the logical link connection request, 
a notification message (and optional user data) is placed in the mailbox 
of the source task. 

— When one task synchronously disconnects or aborts a logical link, a 
notification message (and optional user data) is placed in the mailbox 
of the task from which it is disconnecting. 

• Network status notification messages that inform a task of some unusual 
network occurrence (such as a third-party disconnect). 
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84.3.4 






• Interrupt messages sent by the other task. 


Terminating the Communication Process 

The termination of a logical link signals the end of the communication 
between tasks. 

In transparent communication using higher-level language statements, RMS 
service calls, or system service calls, either task can break the link. To 
terminate the link properly, it is recommended that the receiver, and not 
the transmitter, of the final message issue the close call to break the link. 

The link termination process is complete when the other task issues a link 
termination request. In transparent communication using system service calls, 
the $DASSGN system service call causes the link to be terminated. 

In nontransparent communication using system service calls, you can 
terminate I/O operations over a channel in one of three ways: 

• Synchronous Disconnect ($QIO) —Indicates to the remote receiver that all 
messages sent by the local transmitter have been acknowledged at the 
end-communication layer. This does not guarantee, however, that the 
user of NSP received the data. 

• Disconnect Abort ($QIO) —Indicates to the remote receiver that all messages 
sent have not necessarily been received. To ensure that all messages are 
received before the link is disconnected, the sender must cancel I/O on 
the channel before issuing the abort call. 

• Deassign Channel and Terminate Link ($DASSGN)—Deassigns the 
channel and immediately breaks the link. 

Note that after either a synchronous disconnect or a disconnect abort, you 
can issue a new connection request because you did not deassign the I/O 
channel but merely deaccessed the link. For further information on these 
system service calls, see Section 8.6. 

When a nontransparent task terminates the communication process, a 
notification message indicating that the link is disconnected is placed in 
the mailbox of the affected task. A nontransparent task can send up to 16 
bytes of optional user data, which is also placed in the mailbox. 

By their nature, disconnect operations are of little value in guaranteeing to 
both partners that communication is complete. Therefore, it is recommended 
that the communicating tasks agree on a protocol for terminating 
communication. In general, the receiver, not the transmitter, of the final 
message should disconnect the logical link. 

In general, transparent communication allows you to create a logical link 
between tasks, send and receive data messages, and terminate the logical link 
at the end of the message dialog. The discussion covers general concepts 
implicit in DECnet-VAX task-to-task communication and assumes familiarity 
with the QlO-related material in the VAX/VMS System Services Reference 
Manual. The use of higher-level language statements and RMS service calls 
in transparent task-to-task communication is described in Section 8.5. 
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8.5 Performing Transparent Task-to-Task Operations 

This section describes the system service calls and functions that you can use 
to perform transparent task-to-task communication over the network. You 
can perform these operations using any of the following methods: 

• DCL commands and command procedures 

• Higher-level language programs using appropriate language calls 

• MACRO programs using VAX RMS calls or VAX/VMS system service calls 

See Section 8.7 for examples of transparent task-to-task operations. 


8.5.1 Using DCL Commands and Command Procedures 

To perform transparent task-to-task operations, you can use DCL commands 
to construct and execute command procedures. 

For example, to display information about another system, you can design 
a command procedure that can be invoked as a remote task. Assume that a 
procedure called SHOWBQ.COM is designed to return status information 
about jobs entered in batch queues on the system where it executes. 
Assume also that SHOWBQ.COM resides on node TRNTO. You can 
use SHOWBQ.COM for task-to-task communication by entering a task 
specification string in a TYPE command. For example: 

$ TYPE TRNTO"BROWN JUNE"::"TASK=SHOWBQ" 

See Section 8.7.1 for an example of a command procedure used for task- 
to-task communication. For additional information concerning the design, 
construction, and execution of command procedures, see the Guide to Using 
DCL and Command Procedures on VAX/VMS. 


8.5.2 Using Higher-Level Language Programs 

This section contains examples of higher-level language calls that can be used 
for transparent task-to-task communication. Each higher-level language call 
contains a task specification string as part of its statement. 

Higher-level language tasks can use standard file opening statements to 
request a logical link connection to a remote task. The following examples 
show how to specify a target task, TEST4, running on node TRNTO, in six 
languages supported on VAX/VMS. 

FORTRAN OPEN (UNIT=7,NAME=TRNTO::"TASK=TEST4''',TYPE='NEW / ) 

BASIC OPEN TRNTO: :"TASK=TEST4 / " AS FILE #7 

PL/I OPEN FILE(OUTPUT) TITLE (TRNTO: :"TASK=TEST4'"); 

PASCAL OPEN (PARTNER # 'TRNT0::"TASK=TEST4 , ",NEW); 

COBOL SELECT PARTNER ASSIGN TO "TRNTO:: ,,,/ TASK=TEST4 /,,/// . OPEN OUTPUT PARTNER. 

C F 1=0PEN ("TRNTO::\"TASK=TEST4\ "",2); 
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FORTRAN 

BASIC 

PL/I 

PASCAL 

COBOL 

C 


OPEN (UNIT=2,NAME= / SYS$NET , ,TYPE= / OLD / ) 

OPEN "SYS$NET" AS FILE #2 
OPEN FILE(INPUT) TITLE ('SYS$NET'); 

OPEN (PARTNER/SYSSNET^LD); 

SELECT PARTNER ASSIGN TO "SYS$NET". OPEN INPUT PARTNER. 
F2=OPEN ("SYS$NET",2); 


An example of a FORTRAN program designed for transparent task-to-task 
communication is in Section 8.7.2. 


8.5.3 Using RMS Service calls in MACRO Programs 

You can write a MACRO program or a higher-level program to perform 
transparent task-to-task communications, using RMS service calls. This 
section describes how to use RMS service calls in a MACRO program. 

Note that the RMS $OPEN statement is equivalent to the higher-level 
language statements described in the previous section. 

Once the appropriate FAB and RAB control blocks have been defined, you 
can use the $OPEN statement to specify the target task, TEST4, running on 
node TRNTO. You can initiate the link by specifying the following call, in 
your MACRO program. 

TARGET: 

$FAB FAC=<GET,PUT>,- 
0RG=SEQ,- 

FNM=<N0DE: :"TASK=TEST4”> 

$OPEN FAB=TARGET 

To complete the logical link, the target task performs a file-opening operation 
using the logical name SYS$NET to establish a communications path back to 
the source task. For example: 

REQUESTER: 

$FAB FAC=<GET,PUT>,- 
0RG=SEQ,- 
FNM=<SYS$NET> 

$0PEN FAB=REQUESTER 

As in the case of the target task, the appropriate FABs and RABs must already 
be declared, if the RMS OPEN call is to succeed. On inbound connections, 
DECnet-VAX automatically makes the logical name assignment to SYS$NET. 


8.5.4 Using System Service Calls in MACRO Programs 

You can write MACRO programs or higher-level language programs to 
perform transparent task-to-task communications, using system service calls. 
This section focuses on MACRO programs using system service calls for 
performing these operations. 

Table 8-1 summarizes these calls and their network-related functions. 
Section 8.5.5 presents the format of these calls in more detail. 
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Table 8-1 System Service Calls for Transparent 
Communication 


Call 

Function 

SASSIGN 

Request a logical link connection 

SDASSGN 

Terminate a logical link 

$QIO (IO$_READVBLK) 

Receive a message 

$QIO (IOS—WRITEVBLK) 

Send a message 


These calls allow you to perform task-to-task communication in much the 
same way as you would perform normal I/O operations. Use the $ ASSIGN 
call to assign a logical link I/O channel to a device, which in this case 
is a task that behaves like a full-duplex record-oriented device. You can 
perform read and write operations with this task in either a synchronous or 
asynchronous manner. To exchange messages, use the Queue I/O (QIO) 
requests supported by DECnet-VAX. When all communication completes, 
use the $DASSGN system service call to deassign the channel and thereby 
disconnect the logical link. 


8.5.4.1 Requesting a Logical Link 

To request a logical link and assign an I/O channel, use the $ ASSIGN system 
service. When you issue this call, you must include a task specifier for the 
remote node on which the cooperating task runs. The task specifier identifies 
the remote node and the target task to which you want to establish a logical 
link. 

For example, for the network model described in Chapter 1, you could 
establish a logical link to target task TEST2 on node TRNTO to perform task- 
to-task communication. To create this link, code the following VAX MACRO 
statements in your source program. 

TARGET: .ASCID /TRNTO::"TASK=TEST2"/ 

NETCHAN: .BLKW 1 ; Channel number returned here 


$ASSIGN_S DEVNAM=TARGET,CHAN=NETCHAN 

For debugging or for symmetry, you can develop and run the target task on 
the local node. Use the local node name (or node number 0) plus two colons 
to connect to the local node. 

Once you establish a logical link, you refer to the assigned channel in any 
succeeding call in the MACRO program, either to send or receive messages, 
or to deassign the channel and terminate the logical link. 

Until the connection operation completes, the process is in local event flag 
wait (LEF) state in kernel mode. Therefore, pressing CTRL/Y will not return 
the process to DCL status. The maximum amount of time that the process 
will wait in this state is specified by the NCP command SET EXECUTOR 
with the OUTGOING TIMER parameter. If this timer cannot be set to an 
acceptable value, tasks that accept commands from the terminal should use 
$QIO (IO$_ACCESS) instead of the transparent $ASSIGN call to initiate 
logical links. 
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8.5.4.2 Completing the Logical Link Connection 

The target task completes the logical link by specifying the logical name 
SYS$NET as the devnam argument for the $ASSIGN system service. For 
example: 

LOGNAM: .ASCID /SYS$NET/ 

NETCHAN: .BLKW 1 ; Channel number returned here 


$ASSIGN_S DEVNAM=LOGNAM,CHAN=NETCHAN 

Issue these calls in the target task to complete the logical link connection. The 
target task also specifies a channel to be used in subsequent system service 
calls. 

It is assumed that the remote node is a VAX/VMS system. If the remote node 
on which the target task runs is other than VAX/VMS, you should refer to 
the related DECnet documentation. 


8.5.4.3 Exchanging Messages 

After DECnet-VAX software establishes a logical link with the target task, 
either task can then send or receive messages. However, they must cooperate 
with each other: for each message sent with the $QIO (IO$_WRITEVBLK), 
the other task must issue a corresponding $QIO (IO$_READVBLK) to receive 
the message. 

You must ensure that the tasks allocate enough buffer space for receiving the 
messages; if they do not, a DATAOVERUN error will occur. You must also 
ensure that the end of the dialog can be determined. Finally, one of the two 
tasks must disconnect the logical link. To terminate a logical link properly, 
the receiver, and not the transmitter, of the final message should break the 
link. 


8.5.4.4 Terminating the Logical Link 

Use the $DASSGN system service call to deassign the channel and break off 
the logical link with the cooperating task. This call terminates all pending 
calls for sending and receiving messages, aborts the link immediately, and 
frees the channel associated with that logical link. 


8.5.4.5 Status and Error Reporting 

When a system service completes execution, a status value is always returned. 
The $ASSIGN, $DASSGN, and $QIO system services place the return status 
information in register 0 (RO). For the $QIO system service, a successful 
status return indicates only that the request was queued successfully. All I/O 
completion status information is placed in the I/O status block (IOSB). For 
example, a $QIO system service read request to a task might be successful 
(status return is SS$_NORMAL) yet fail because the link was disconnected. 
(I/O status return is SS$_LINKABORT.) The return status codes shown in 
the following sections may be returned both in RO and in the IOSB. 

The VAX/VMS System Services Reference Manual and the Guide to Programming 
on VAX/VMS both describe the use of asynchronous system traps (ASTs), 
IOSBs, and event flags. 
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8.5.5 Summary of System Service Calls for Transparent Operations 

The following sections describe the VAX/VMS system services you can use 
for transparent intertask communication. Each description covers the use of 
the call, its format, the arguments associated with the call, and the return 
status information. The VAX/VMS System Messages and Recovery Procedures 
Reference Manual lists the entire set of network system service error messages. 

8.5.5.1 SASSIGN 

The $ASSIGN system service assigns a channel to refer to the logical 
link. You can then use the channel returned in the chan argument in any 
succeeding call to send or receive a message, or to deassign the channel and 
thereby terminate the logical link. 

Format 

$ASSIGN devnam ,chan , [acmode] 

Arguments 

devnam Address of a quadword descriptor of a character string that identifies 
the remote task. The string will contain either of the following: 

• A task specification string if the call is by the source task. Both 
the string and its descriptor must be in read/write storage. 

• SYSSNET if the call is by the target task. (SYSSNET is a logical 
name.) 

chan Address of a word that will receive the assigned channel number. You 

use this channel number to send a message to a remote task, receive 
a message from a remote task, or to abort the logical link. 

acmode Access mode to be associated with this channel. The most privileged 
access mode used is the access mode of the caller. You can perform 
I/O operations on the channel only from equal or more privileged 
access modes. 


Return Status 


SS$_REMOTE 

The service completed successfully. (A logical link was 
established with the target task.) 

SS$_CONNECFAIL 

The connection to a network object timed out or failed. 

SS$_DEVOFFLINE 

The physical link is shutting down. 

SS$_FILALRACC 

A logical link already exists on the channel. 

SS$_INSFMEM 

There is not enough system dynamic memory to 
complete the request. 

SS$_INVLOGIN 

The access control information was found to be invalid 
at the remote node. 

S$_IVDEVNAM 

The task specifier has an invalid format or content. 

SS$_LINKEXIT 

The network partner task was started, but exited 
before confirming the logical link (that is, SASSIGN to 
SYSSNET). 
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8.5.5.2 


SS$_NOLINKS 

SSS—NOPRIV 

SS$_NOSUCHNODE 

SS$_NOSUCHOBJ 

SS$_NOSUCHUSER 

SS$_PROT OCOL 

SS$_REJECT 

SS$_REMRSRC 

SS$_SHUT 

SS$_THIRDPARTY 

SS$_TOOMUCHDATA 

SS$_UNREACHABLE 


No logical links are available. The maximum number 
of logical links as set for the NCP executor MAXIMUM 
LINKS parameter was exceeded. 

The issuing task does not have the required privilege to 
perform network operations or to confirm the specified 
logical link. 

The specified node is unknown. 

The network object number is unknown at the remote 
node; or for a TASK= connect, the named DCL 
command procedure file cannot be found at the remote 
node. 

The remote node could not recognize the login 
information supplied with the connection request. 

A network protocol error occurred, most likely because 
of a network software error. 

The network object rejected the connection. 

The link could not be established because system 
resources at the remote node were insufficient. 

The local or remote node is no longer accepting 
connections. 

The logical link connection was terminated by a third 
party (for example, the system manager). 

The task specified too much optional or interrupt data. 
The remote node is currently unreachable. 


$QIO (Sending a Message to a Target Task) 

The $QIO system service with a function code of IO$_WRITEVBLK sends 
a message to a target task. The $QIO call initiates an output operation 
by queuing a request to the channel associated with the logical link. 
Alternatively, you could use the $QIOW system service to perform the 
same operation but wait for I/O completion. 


Format 

)$QI0 i [ e fn] .chan ,func , [iosb] ,[astadr] , [astprm] ,pl ,p2 

($QI0W( 

Arguments 

efn Number of the event flag to be set at request completion. 

chan A word containing the channel number associated with the logical link. 

Use the same channel number returned previously in the $ASSIGN call. 

func IO$_WRITEVBLK 

iosb Address of a quadword I/O status block that is to receive the 

completion status. 

astadr Entry point address of an AST routine that executes when the I/O 
operation completes. If specified, the AST routine executes at the 
access mode from which the $QIO service was requested. 
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8.5.5.3 


astprm AST parameter to be passed to the AST completion routine, 
pi Buffer address. 

p2 Buffer length in bytes. 


Return Status 

SSS—NORMAL 

SS$_ABORT 

SS$_CANCEL 
SS$_FILNOT ACC 
SS$_INSFMEM 

SS$_LINK ABORT 
SS$_LINKDISCON 
SS$_LINKEXIT 
SS$_PATHLOST 
SS$_PROT OCOL 

SS$_THIRDPARTY 


The service completed successfully. 

The I/O request has been aborted by a $DASSGN or 
$CANCEL. 

The I/O on this channel has been canceled. 

No logical link is associated with the channel. 

Enough memory to buffer the message could not be 
allocated. 

The network partner task aborted the logical link. 

The network partner task disconnected the logical link. 
The network partner task exited. 

The path to the network partner task node was lost. 

A network protocol error occurred. This is most likely 
due to a network software error. 

The logical link connection was terminated by a third 
party (for example, the system manager). 


$QIO (Receiving a Message from a Target Task) 

The $QIO system service with a function code of IO$_READVBLK receives 
a message from a target task. The $QIO call initiates an input operation 
by queuing a request to the channel associated with the logical link. 
Alternatively, you could use the $QIOW system service to perform the 
same operation but wait for I/O completion. 


Format 

[efn] .chan ,func ,[iosb] ,[astadr] .[astprm] ,pl ,p2 

Arguments 

efn Number of the event flag to be set at request completion. 

chan A word containing the channel number associated with the logical link. 

Use the same channel number returned previously in the SASSIGN call. 

func IO$_READVBLK 

iosb Address of a quadword I/O status block that is to receive the 

completion status. 

astadr Entry point address of an AST routine that executes when the I/O 
operation completes. If specified, the AST routine executes at the 
access mode from which the $QIO service was requested. 

astprm AST parameter to be passed to the AST completion routine. 


$QI0 

$QI0W 
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8.5.54 


pi Buffer address. 

p2 Buffer length in bytes. 


Return Status 

SS$_NORMAL 

SS$_ABORT 

SS$_CANCEL 
SS$_DAT AOVERUN 

SS$_FILNOT ACC 
SS$_INSFMEM 

SS$_LINK ABORT 
SS$_LINKDISCON 
SS$_LINKEXIT 
SS$_PATHLOST 
SS$_PROT OCOL 

SS$_THIRDPARTY 


The service completed successfully. 

The I/O request has been aborted by a $DASSGN or 
SCANCEL. 

The I/O on this channel has been canceled. 

More bytes were sent than could be received in the 
supplied buffer. 

No logical link is associated with the channel. 

Enough memory to buffer the message could not be 
allocated. 

The network partner task aborted the logical link. 

The network partner task disconnected the logical link. 
The network partner task exited. 

The path to the network partner task node was lost. 

A network protocol error occurred. This is most likely 
due to a network software error. 

The logical link connection was terminated by a third 
party (for example, the system manager). 


$DASSGN (Terminating a Logical Link) 

The $DASSGN system service terminates all pending operations to send and 
receive data, disconnects the logical link immediately, and frees the channel 
associated with that link. Either task can terminate the logical link by calling 
$DASSGN. 


Format 

$DASSGN chan 


Arguments 

chan A word containing the channel number to the logical link you want 

disconnected. Use the same channel number returned previously in the 
SASSIGN call. 


Return Status 

SS$_NORMAL The service completed successfully. 

SS$_IVCHAN An invalid channel number was specified. 

SS$_NOPRIV The specified channel was not assigned or was assigned from 
a more privileged access mode. 


8.6 Performing Nontransparent Task-to-Task Operations 

This section describes the system service calls and functions that you use 
for nontransparent task-to-task communication. In general, the principles of 
nontransparent task-to-task communication are similar to those of transparent 
communication. 
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If you wish to perform nontransparent communication operations, you can 
write VAX MACRO programs using VAX/VMS system services designed 
specifically for DECnet-VAX. You can also write programs in one of the 
higher-level languages, provided that the language supports the DECnet-VAX 
services. These DECnet-VAX services are described in detail throughout this 
section. 

DECnet-VAX also provides additional services with extensions that allow you 
to use network-specific features for nontransparent network operations such 
as the following: 

• Creating and using mailboxes for receiving messages, including network 
status notifications 

• Declaring a task as a network task, thus enabling it to process multiple 
inbound logical link connection requests 

• Sending connection requests, optionally with user data 

• Accepting or rejecting a connection request, optionally with user data 

• Communicating between a transparent and a nontransparent task 

• Sending or receiving an interrupt message 

• Aborting or synchronously disconnecting a logical link, optionally with 
user data 

The general concepts implicit in DECnet-VAX task-to-task communication 
are covered in Section 8.5. You should also be familiar with the material 
contained in the VAX/VMS System Routines Reference Volume and the 
VAX/VMS I/O Reference Volume. 


8.6.1 Using System Services for Nontransparent Operations 

Nontransparent task-to-task communication over the network uses a set of 
system service calls available under the VAX/VMS operating system. Table 
8-2 summarizes these calls and their network-related functions. The $QIO 
calls are distinguished by function code. 


Table 8-2 System Service Calls for Nontransparent 
Communication 


Call 

SASSIGN 

$CANCEL 

SCREMBX 

$DASSGN 

$GETDVI 

$QIO (IO$_ACCESS) 
$QIO (IO$_ACCESS) 


Function 

Assign an I/O channel 
Cancel I/O on a channel 
Create a mailbox 

Abort the logical link connection 
(deassigning an I/O channel) 

Get information on device or 
volume 

Request a logical link connection 

Accept a logical link connection 
request 
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Table 8-2 (Cont.) System Service Calls for Nontransparent 
Communication 


Call 

$QIO (IO$_ACCESS!IO$M_ABORT) 

$QIO (IO$_ACPCONTROL) 

$QIO (IO$_DEACCESS!IO$M_ABORT) 

$QIO (IO$_DEACCESS!IO$M_SYNCH) 

$QIO (IO$_READVBLK) 

$QIO (IO$_WRITEVBLK) 

$QIO (IO$_WRITEVBLK!IO$M_INTERRUPT) 
STRNLNM 


Function 

Reject a logical link connection 
request 

Assign a network name to a 
task eligible to accept multiple 
inbound connection requests 

Abort the logical link connection 

Synchronously disconnect a 
logical link 

Receive a message 
Send a message 
Send an interrupt message 
Translate logical names 


8.6.1.1 Assigning a Channel to _NET: and Creating a Mailbox 

To prepare for nontransparent task-to-task communication, you need to assign 
a channel just as you would for transparent communication. In addition, you 
can create a mailbox to take advantage of optional network protocol features. 

You must assign a channel to a pseudodevice called _NET:; use the $ ASSIGN 
system service call for this purpose. This call normally contains a reference 
to a mailbox, thereby associating it with the channel assigned to _NET:. If 
you use a mailbox, you must create the mailbox before assigning a channel to 
_NET:. It is important to note that this use of the $ ASSIGN system service 
differs from its use for transparent communication. Assigning a channel to 
—NET: does not transmit a logical link connection request to the remote 
node. Instead, the channel to —NET: provides a communication path to 
DECnet software. A separate $QIO call (IO$_ACCESS function using the 
same channel) must be used to request a logical link to the remote task. 

To take advantage of optional network protocol features, you can create a 
mailbox to receive messages on behalf of logical link operations. For example, 
the mailbox receives a message indicating whether the cooperating task 
accepted or rejected a connection request issued by the source task. Use the 
$CREMBX system service to create a mailbox for these purposes. In the event 
that your application does not use mailbox messages, you need not create a 
mailbox. 

For convenience, the Run-Time Library routine LIB$ASN_WTH_MBX can 
be used to create a temporary mailbox, assign a channel to it, and assign a 
channel to —NET:. This routine creates a unique mailbox in that multiple 
copies of the task using it will in effect use different mailboxes. If you were 
to create a mailbox with a logical name, all tasks would use the same mailbox 
and thereby interfere with each other's mailbox messages. For a complete 
description of this routine, see the VAX/VMS Run-Time Library Routines 
Reference Manual. 
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8.6.1.2 Mailbox Message Format 

The mailbox receives information specific to nontransparent communication 
with a remote task. Figure 8-2 illustrates the general format of the mailbox 
message. 

Figure 8-2 Mailbox Message Format 
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Notes to Figure 8—2 


MSGTYPE 

UNIT 

COUNT NAME 

COUNT INFO 


Contains a code that identifies the message type. 

Contains the binary unit number of the device for which the 
message applies. 

Contains a counted ASCII string that gives the name of the 
device for which the message applies. The SASSIGN system 
service creates devices having names of "NET". 

Contains a counted ASCII string of information which depends 
on the message type. 


The VAX/VMS System Services Reference Manual summarizes the mailbox 
messages that pertain to nontransparent task-to-task communication. 


Requesting a Logical Link Connection 

Once you assign the I/O channel, you can request a logical link connection 
to the target task. Use the $QIO system service with a function code of 
IO$_ACCESS. You must identify the target task in the $QIO call. Use a 
network connect block (NCB) to specify the target task identification string. 
In addition, you can optionally send 1 to 16 bytes of data in the NCB. The 
NCB must be in read/write storage. The format of the NCB is discussed in 
Section 8.6.1.4. 

Once the source task issues the connection request, it can then issue a $QIO 
call with a function code of IO$_READVBLK to read its mailbox. Checking 
the contents of the mailbox is one way to determine whether the target task 
accepted or rejected the connection request. The mailbox will contain either 
MSG$_CONFIRM or MSG$_REJECT, possibly with optional data in the 
mailbox buffer. 

If specified, the IOSB argument of the $QIO (IO$_ACCESS) call will also 
contain the result of the connection request operation. Section 8.6.2.2 
provides a complete list of I/O status messages for this call. 
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Note that you must read the mailbox to inspect any optional data sent from 
the target task upon accepting or rejecting the connection request. 


8.6.1.4 Using the Network Connect Block 

The network connect block is a user-generated data structure that contains 
the information necessary to request a logical link connection or to accept or 
reject a logical link connection request. 

Example 8-1 is an example of an NCB you could use when issuing a 
connection request call. 

The significance of the information contained in the NCB block varies, 
depending on the type of call in which it is used. If the call is an outbound 
connection request with no optional data, items 2, 3, 4, and 5 of the block are 
not required. If the call is a connect accept operation and no optional data is 
sent, then items 4 and 5 are not required. Item 5 is meaningful only to the 
receiver of a connection request. 

Example 8-1 Network Connect Block Format 


1. With optional data (outbound connect): 

o © 

NCB: .ASCII ?TRNT0::"TASK=TEST2/? 

. WORD 0© 

OPTDATA: 

.ASCIC /USERINFO/ 

. BLKB 17-< . -0PTDATA>© 

.ASCII /"/ 

0 

2. Without optional data (outbound connect): 

© 

NCB: .ASCII 7TRNT0::"TASK=TEST2"? 


Item Function 

© A valid task specification string. For an inbound call with an NCB, the 
task name portion of the task specification string is a process ID if the 
remote node is a VAX/VMS system; if not, then the task name portion 
is a system-specific string that identifies an executable unit (for example, 
job or task). The task specification string must be a quoted string. Note 
that the final quotation mark of the task specification string follows the 
last item within the NCB. 

© The slash character (/). 

© One word. This word must be 0 for a connection request operation. 

For a connect accept or reject operation, this word contains an internal 
DECnet link identifier. 

© Up to 16 bytes of optional data sent as a counted string. This string 
is stored in a fixed-length field that is 17 bytes long. DECnet-VAX 
software ignores unused bytes. 


8-25 






Performing Network User Operations 


© A destination descriptor. This descriptor indicates how the connection 
was issued and is meaningful only to the task or object to which the 
connection is made. This information is useful where one program 
serves many functions and needs to know how it was invoked. The 
maximum length for the destination descriptor is 19 bytes. The format is 
as follows: 

a If byte 0 contains 0, then byte 1 is the binary value of the object 
number. 

b If byte 0 contains 1, then byte 1 is the binary object number, and 
bytes 2 through 18 contain a counted task name. 

C If byte 0 contains 2, then byte 1 is the binary object number, bytes 2 
through 5 contain a UIC, the first two bytes of which contain a binary 
group code and the second two bytes contain a binary user code, and 
bytes 6 through 18 contain a counted task name. 


8.6.1.5 Completing the Logical Link 

A nontransparent target task completes the logical link connection in one of 
several ways, depending upon whether the task can process multiple inbound 
connection requests or just a single request. Furthermore, a nontransparent 
target task has the option of accepting or explicitly rejecting a logical link 
request. 

Receiving Connection Requests 

This section describes what happens when you receive single and multiple 
connection requests. It is assumed that the remote node is VAX/VMS. If the 
remote node on which your target task runs is other than VAX/VMS, you 
should refer to the related DECnet documentation. 

When a remote node receives a call requesting a logical link, the DECnet- 
VAX software constructs an NCB from the information contained in the call. 
At this point, one of two things occurs. If a process already running on the 
remote node has declared a network name or object number the same as the 
one identified in the NCB, then the software puts the NCB into that process's 
mailbox. If not, DECnet-VAX software either uses a compatible netserver 
process (if one exists) or creates a netserver process (if one does not already 
exist) to execute NETSERVER.COM, which in turn will run NETSERVER.EXE. 

SYS$NET is equated to the NCB, and LOGIN.COM (if it exists) is invoked, 
which in turn starts the taskname.COM command file. The name of this 
command file is determined as follows: 

• If the connection request identifies a numbered (nonzero) object, then 
the appropriate record is located in the configuration database and the 
name of the file is found in this record. (The file is assumed to reside in 
SYS$SYSTEM.) 

• If the connection request identifies a named object with type 0 (TASK), 
then the file name is assumed to be the name of the task connected to 
(with a file type of COM) and is assumed to reside in the default directory 
associated with the access control information. 

Once executing, the target task can then determine whether to accept or 
explicitly reject the connection request. You can program the target task to 
base this assessment on the information contained in the NCB. 
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A nontransparent target task can accept only one connection request at a 
time, unless it declares itself as a network task. The target task may retrieve 
the connection information by translating the logical name SYS$NET using 
the $TRNLNM system service. Once the task retrieves the logical name, it 
may then decide whether to accept or explicitly reject the connection request. 

Note that you need to translate SYS$NET only if you require the following 
information: 

• The optional data in the network connect block 

• The identity of the connector 

• The descriptor by which the connection was made 

A target task can accept multiple inbound connection requests only if it 
declares itself a known network task. To make this declaration, you must 
first use the $ ASSIGN call to assign an I/O channel to _NET:. Then, use 
the $QIO system service with a function code of IO$_ACPCONTROL to 
assign a network name or object number to the task, making it eligible to 
process multiple inbound connection requests. This system service requires 
SYSNAM privilege. You must associate a mailbox with the channel if a name 
or number is to be declared. 

Programs that have declared names or object numbers should be programmed 
to terminate when their mailboxes receive a MSG$_NETSHUT message. 
Such programs must be restarted when the network comes back up. 

Once you declare the target task as an active network task, DECnet places 
all connection requests addressed to the task in the mailbox associated with 
the channel over which the ACP control function was issued. The target task 
retrieves connection requests from the mailbox by issuing the $QIO system 
service call with a function code of IO$_READVBLK. Note that the first 
message in the mailbox is the NCB from the original connection request that 
put the task into a state of execution. Once the task declares a network name 
or object number, subsequent inbound connection requests are not checked 
for their access control information. (However, if the network task is started 
separately from a DECnet operation, access control is never checked.) 

Note that you can start programs that declare names or object numbers apart 
from the first inbound connection (that is, by a RUN command). 

Accepting or Rejecting a Connection Request 

The target task can either accept or explicitly reject a connection request. To 
accept a connection request, thus completing the logical link connection, use 
the $QIO system service with a function code of IO$_ACCESS. To reject 
the connection request, use the $QIO system service with the function code 
IO$_ACCESS!IO$M_ABORT. When it either accepts or rejects the connection 
request, the target task can also send 1 to 16 bytes of optional data within a 
modified NCB back to the source task. 

Exchanging Data Messages and Receiving Interrupt Messages 

The exchange of data messages between the two cooperating tasks is 
performed in the same way for both nontransparent and transparent 
communication. (Refer to Section 8.5.5 for information on using the system 
service calls $QIO (IO$_WRITEVBLK) and $QIO (IO$_READVBLK) to send 
and receive messages.) 


8—27 


Performing Network User Operations 


The receiving of information applies only to nontransparent communication. 
Either task can send a 1- to 16-byte interrupt message. You can use this 
method to send a message to a target task outside the normal flow of data 
messages. DECnet-VAX places the received interrupt message in the target 
task's mailbox. Use the $QIO system service with a function code of 
IO$_WRITEVBLK!IO$M—INTERRUPT to send the interrupt message. To 
notify the target task that an interrupt message has been placed in its mailbox, 
the task should issue a $QIO system service call with a function code of 
IO$_READVBLK to the mailbox. Specifying an AST routine in the $QIO 
system service call will cause the routine to be executed on receiving the 
interrupt message. (AST routines are described in the VAX/VMS System 
Services Reference Manual. 


8.6.1.6 Disconnecting or Aborting the Logical Link 

A nontransparent task can terminate communication with a remote task 
either by disconnecting the link (synchronous disconnect or disconnect abort) 
or by deassigning the channel. In the first instance, you can issue a new 
connection request on the same channel because you do not deassign it. 

If you specifically use the IO$_DEACCESS, as opposed to the SDASSGN 
method of terminating a link, you can send an optional message of 1 to 16 
bytes of data with the $QIO call. 

To disconnect a logical link synchronously, issue the $QIO system service 
with a function code of IO$_DEACCESS!IO$M_SYNCH. The channel is then 
free for subsequent communication with either the same or a different remote 
task. 

A synchronous disconnect may be useful for master/slave communication, in 
which one task always sends data and its partner task always receives data. If 
the receiving task is notified of a synchronous disconnection, then all the data 
that was sent has been received. (The sending task, on the other hand, is not 
guaranteed that its partner received the data.) Because this notification is the 
only guarantee provided by this operation, using this operation is discouraged 
in favor of a user-defined protocol to ensure completion of communication. 

In general, the receiver of the final message should break the logical link. 

To abort the logical link, issue the $QIO system service with a function code 
of IO$_DEACCESS!IO$M_ABORT. This form of disconnection indicates to 
the receiver that not all messages sent have necessarily been received. To 
ensure that all transmitted messages have been received, the task itself must 
terminate I/O operations on the link before instituting the DEACCESS 
function because this function never completes before all pending I/O 
operations complete. To do so, first issue the $CANCEL system service to 
terminate I/O operations over the link; then, issue the $QIO system service 
to terminate the link. 

Note that after either a synchronous disconnect or a disconnect abort, you can 
issue a new connection request if you did not deassign the I/O channel. 

If you issue the $CANCEL system service to a channel over which a network 
name or object has been declared, the declaration will be removed from the 
network database. 
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8.6.1.7 Terminating the Logical Link 

You can issue the $DASSGN system service call to deassign the channel 
and terminate the logical link immediately. You issue the call only after all 
communication between the tasks is complete. The call releases the I/O 
channel, disassociates the mailbox from the channel, and terminates the 
logical link immediately. This operation is equivalent to using $CANCEL 
followed by $QIO IO$_DEACCESS!IO$M_ABORT. 

The same status and error reporting considerations apply to nontransparent 
as to transparent task-to-task communication. Refer to Section 8.5.4.5 for 
information on status and error reporting. 


8.6.2 System Service Calls for Nontransparent Operations 

The following sections describe the VAX/VMS system services you can use for 
nontransparent intertask communication over the network. Each description 
covers the use of the call, its format, the arguments associated with the 
call, and the return status information. The VAX/VMS System Messages and 
Recovery Procedures Reference Manual lists the entire set of network system 
service error messages. 

The following system services are not described in detail below, because 
their use does not change in a networking context. For a description of these 
system services, see the VAX/VMS System Services Reference Manual. 

• $CANCEL (Cancel I/O on Channel) 

• $CREMBX (Create Mailbox and Assign Channel) 

• $GETDVI (Get Device/Volume Information) 

Note that $GETDVI performs the same function as the Get I/O Channel 
Information ($GETCHN) system service. However, DIGITAL recommends 
that you use the $GETDVI system service. 

8.6.2.1 $ASSIGN (I/O Channel Assignment) 

The $ASSIGN system service assigns a channel to refer to a logical link. You 
use this channel in all $QIO calls that communicate with a remote task. In 
addition, you can use the $ASSIGN system service call to associate a mailbox 
with the channel. 

Format 

$ASSIGN devnam .chan , [acmode] .[mbxnam] 

Arguments 

devnam Address of a quadword descriptor of a character string containing the 
string _NET: or a logical name for _NET:. 

chan Address of a word that will receive the assigned channel number. 
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acmode Access mode to be associated with this channel. The most privileged 
access mode used is the access mode of the caller. You can perform 
I/O operations on the channel only from equal or more privileged 
access modes. 

mbxnam Address of a character string descriptor for the physical name 
of the mailbox to be associated with the channel. This mailbox 
remains associated with the channel until the channel is deassigned 
($DASSGN). 


Return Status 

SSS—NORMAL 

SS$_INSFMEM 

SS$_NOPRIV 

SS$_NOSUCHDEV 


The service completed successfully. 

There is not enough system dynamic memory to complete 
the request. 

The issuing task does not have the required privileges to 
create the channel. 

The network device driver is not loaded (for example, the 
DECnet-VAX software is not running currently on the local 
node). 


$QIO (Requesting a Logical Link Connection) 

The $QIO system service with a function code of IO$__ACCESS requests 
a logical link connection to a target task. You can send 1 to 16 bytes of 
optional data to the target task at the same time that you issue the $QIO 
system service. 

Format 

$QIO [efn] .chan ,func ,[iosb] ,[astadr] , [astprm] , [pi] ,p2 


Arguments 

efn 
chan 


func 

iosb 

astadr 


astprm 

Pi 

p2 


Number of the event flag to be set at request completion. 

The channel number associated with the logical link. Use the same 
channel number returned previously in the $ASSIGN call. 

IO$_ACCESS 

Address of a quadword I/O status block that is to receive the 
completion status. 

Entry point address of an AST routine that executes when the I/O 
operation completes. If specified, the AST routine executes at the 
access mode from which the $QIO service was requested. 

AST parameter to be passed to the AST completion routine. 

Not used (omit the argument). 

address of a quadword descriptor of the NCB (see Section 8.6.1.4). 
Both the descriptor and the NCB must be in read/write storage. 


Return Status 


SS$_NORMAL 

The 

SS$_CONNECFAIL 

The 

SS$_DEVOFFLINE 

The 
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SSS—FILALRACC 

SS$_INSFMEM 

SS$_INVLOGIN 

SS$_IVDEVNAM 

SS$_LINKEXIT 

SS$_NOLINKS 

SSS—NOPRIV 

SS$_NOSUCHNODE 

SS$_NOSUCHOBJ 

SS$_NOSUCHUSER 

SS$_PROT OCOL 

SS$_REJECT 

SS$_REMRSRC 

SS$_SHUT 

SS$_THIRDPARTY 

SS$_T OOMUCHD AT A 
SS$_UNREACHABLE 


A logical link is already accessed on the channel (that 
is, a previous connection is active on the channel). 

There is not enough system dynamic memory to 
complete the request. 

The access control information was found to be invalid 
at the remote node. 

The NCB has an invalid format or content. 

The network partner task was started, but exited 
before confirming the logical link (that is, SASSIGN to 
SYS$NET). 

No logical links are available. The maximum number of 
logical links as set for the executor MAXIMUM LINKS 
parameter was exceeded. 

The issuing task does not have the required privileges 
to create a logical link to the designated target. 

The specified node is unknown. 

The network object number is unknown at the remote 
node; or for a TASK= connect, the named DCL 
command procedure file cannot be found at the remote 
node. 

The remote node could not recognize the login 
information supplied with the connection request. 

A network protocol error occurred. This error is most 
likely due to a network software error. 

The network object rejected the connection. 

The link could not be established because system 
resources at the remote node were insufficient. 

The local or remote node is no longer accepting 
connections. 

The logical link was terminated by a third party (for 
example, the system manager). 

The task specified too much optional or interrupt data. 
The remote node is currently unreachable. 


$QIO (Accepting Logical Link Connection Request) 

The $QIO system service with a function code of IO$_ACCESS accepts a 
logical link connection request from a source task. You can send 1 to 16 bytes 
of optional data to the source task at the same time that you issue the $QIO 
system service. 

Format 

$QI0 [efn] .chan ,func , [iosb] ,[astadr] ,[astprm] , [pi] ,p2 


Arguments 

efn Number of the event flag to be set at request completion. 

chan The channel number associated with the logical link. Use the same 

channel number returned previously in the SASSIGN call. 

func IO$_ACCESS 
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iosb Address of a quadword I/O status block that is to receive the 

completion status. 

astadr Entry point address of an AST routine that executes when the I/O 
operation completes. If specified, the AST routine executes at the 
access mode from which the $QIO service was requested. 

astprm AST parameter to be passed to the AST completion routine. 

pi Not used (omit the argument). 

p2 Address of a quadword descriptor of the NCB (see Section 8.6.1.4). 

Both the descriptor and the NCB must be in read/write storage. 


Return Status 

SS$_NORMAL 
SS$_DEV ALLOC 

SS$_EXQUOT A 

SS$_INSFMEM 

SS$_IVDEVNAM 

SS$_LINKABORT 

SS$__LINKDISCON 

SS$_LINKEXIT 

SS$_NOSUCHNODE 

SS$_PATHLOST 

SS$_PROTOCOL 

SS$_THIRDPARTY 

SS$_TIMEOUT 

SS$_UNREACHABLE 


The service completed successfully. 

The process cannot access the logical link specified 
in the NCB because that link is intended for another 
process. 

The process does not have sufficient quota to 
complete the request. 

There is not enough system dynamic memory to 
complete the request. 

The NCB has an invalid format or content. 

The network partner task aborted the logical link. 

The network partner task disconnected the logical link. 
The network partner task exited. 

The specified node is unknown. 

The path to the network partner task node was lost. 

A network protocol error occurred. This error is most 
likely due to a network software error. 

The logical link connection was terminated by a third 
party (for example, the system manager). 

The connection request did not complete within the 
required time. 

The remote node is currently unreachable. 


$QIO (Rejecting a Logical Link Connection Request) 

The $QIO system service with a function code of IO$_ACCESS!IO$M_ 
ABORT rejects a logical link connection request. You can send 1 to 16 bytes 
of optional data to the target task at the same time that you issue the $QIO 
system service. 

Format 

$QI0 [efn] ,chan .rune ,[iosb] , [astadr] .[astprm] ,[pi] ,p2 


Arguments 

efn Number of the event flag to be set at request completion. 

chan The channel number associated with the logical link. Use the same 

channel number returned previously in the $ASSIGN call. 

func IO$_ACCESS!IO$M _ABORT 
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iosb Address of a quadword I/O status block that is to receive the 

completion status. 

astadr Entry point address of an AST routine that executes when the I/O 
operation completes. If specified, the AST routine executes at the 
access mode from which the $QIO service was requested. 

astprm AST parameter to be passed to the AST completion routine. 

pi Not used (omit the argument). 

p2 Address of a quadword descriptor of the NCB (see Section 8.6.1.4). 

Both the descriptor and the NCB must be in read/write storage. 


Return Status 

SS$_NORMAL 
SS$_DEV ALLOC 


SS$_EXQUOT A 

SS$_IVDEVNAM 

SSS—LINK ABORT 

SS$_LINKDISCON 

SS$_LINKEXIT 

SS$_NOSUCHNODE 

SS$_TIMEOUT 

SS$_PATHLOST 
SS$_PROT OCOL 

SS$_THIRDPARTY 

SS$_UNREACHABLE 


The service completed successfully. 

The process cannot access the logical link specified 
in the NCB because that link is intended for another 
process. 

The process does not have sufficient quota to complete 
the request. 

The NCB has an invalid format or content. 

The network partner task aborted the logical link. 

The network partner task disconnected the logical link. 
The network partner task exited. 

The specified node is unknown. 

The connection request did not complete within the 
required time. 

The path to the network partner task node was lost. 

A network protocol error occurred. This error is most 
likely due to a network software error. 

The logical link connection was terminated by a third 
party (for example, the system manager). 

The remote node is currently unreachable. 


$QIO (Sending a Message To a Target Task) 

The $QIO system service with a function code of IO$_WRITEVBLK sends a 
message to a target task. Refer to Section 8.6.2.7 for the format of this call, 
its arguments, and possible return status codes. Note that you must substitute 
IO$_WRITEVBLK for IO$_WRITEVBLK!IO$M_INTERRUPT as the function 
code. 


8.6.2.6 $QIO (Receiving a Message From a Target Task) 

The $QIO system service with a function code of IO$_READVBLK receives a 
message from a target task. Refer to Section 8.6.2.7 for the format of this call, 
its arguments, and possible return status codes. 
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8.6.2.7 


8 . 6 . 2.8 


$QIO (Sending an Interrupt Message To a Target Task) 

The $QIO system service with a function code of IO$_WRITEVBLK!IO$M_ 
INTERRUPT sends a 1- to 16-byte interrupt message to a target task. If the 
remote node is a VAX/VMS system, the message is placed in the mailbox 
associated with the target task. 

Format 

$QI0 [efn] .chan ,func , [iosb] , [astadr] ,[astprm] ,pl ,p2 


Arguments 

efn Number of the event flag to be set at event completion. 

chan The channel number associated with the logical link. Use the same 
channel number returned previously in the $ASSIGN call. 

func IO$_WRITEVBLK!IO$M_INTERRUPT 

iosb Address of a quadword I/O status block that will receive the 

completion status. 

astadr Entry point address of the AST routine that executes when the I/O 
operation completes. If specified, the AST routine executes at the 
access mode from which the $QIO service was requested. 

astprm The AST parameter to be passed to the AST completion routine. 

pi Buffer address. 

p2 Buffer length (1 to 16 bytes). 


Return Status 

SS$_NORMAL 

SS$_ABORT 

SS$_FILNOT ACC 
SS$_INSFMEM 

SS$_LINK ABORT 
SS$_LINKDISCON 
SS$_LINKEXIT 
SS$_NOSOLICIT 

SS$_TOOMUCHDAT A 
SS$_PATHLOST 
SS$_PROT OCOL 

SS$_THIRDPARTY 


The service completed successfully. 

The I/O request has been aborted by a $DASSGN or 
SCANCEL call. 

No logical link is associated with the channel. 

Enough memory to buffer the message could not be 
allocated. 

The network partner task aborted the logical link. 

The network partner task disconnected the logical link. 
The network partner task exited. 

DECnet could not accept an interrupt message at this 
time. 

The task specified too much interrupt data. 

The path to the network partner task node was lost. 

A network protocol error occurred. This error is most 
likely due to a network software error. 

The logical link connection was terminated by a third 
party (for example, the system manager). 


$QIO (Synchronously Disconnecting a Logical Link) 

The $QIO system service with a function code of IO$_DEACCESS!IO$M_ 
SYNCH synchronously disconnects the logical link. All pending messages are 
transmitted to the remote node before the link is disconnected. 

You can send 1 to 16 bytes of optional data to the task from which you are 
disconnecting at the same time you issue this $QIO system service. 
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Format 

$QI0 [efn] .chan ,func , [iosb] ,[astadr] , [astprm] , [pi] , [p2] 

Arguments 

efn Number of the event flag to be set at event completion. 

chan The channel number associated with the logical link. Use the same 

channel number returned previously in the SASSIGN call. 

func IO$_DEACCESS!IO$M—SYNCH 

iosb Address of a quadword I/O status block that will receive the 

completion status. 

astadr Entry point address of the AST routine that executes when the I/O 
operation completes. If specified, the AST routine executes at the 
access mode from which the $QIO service was requested. 

astprm The AST parameter to be passed to the AST completion routine, 
pi Not used (omit the argument). 

p2 Address of a descriptor of a counted ASCII string of optional user 

data. Both the string and its descriptor must be in read/write storage. 

Return Status 

SS$_NORMAL The service completed successfully. 

SS$_FILNOTACC No logical link is associated with the channel. 

8.6.2.9 $QIO (Aborting a Logical Link) 

The $QIO system service with a function code of IO$_DEACCESS!IO$_ 
ABORT terminates the logical link. Note, however, that the DEACCESS 
function completes only after all pending I/O operations complete, even 
though you specify IO$_ABORT. First, issue the $CANCEL system service 
call to cancel I/O operations on the logical link and then issue this call to 
terminate the logical link. 

You can send 1 to 16 bytes of optional data to the task from which you are 
disconnecting at the same time that you issue this $QIO system service call. 

Format 

$QI0 [efn] .chan ,func .[iosb] .[astadr] .[astprm] ,[pi] , [p2] 

Arguments 

efn Number of the event flag to be set at event completion. 

chan The channel number associated with the logical link. Use the same 

channel number returned previously in the SASSIGN call. 

func IO$_DE ACCESS! IO$M_ABORT 

iosb Address of a quadword I/O status block that will receive the 

completion status. 

astadr Entry point address of the AST routine that executes when the I/O 
operation completes. If specified, the AST routine executes at the 
access mode from which the $QIO service was requested. 
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8 . 6 . 2.10 


astprm The AST parameter to be passed to the AST completion routine, 
pi Not used (omit the argument). 

p2 Address of a quadword descriptor of a counted string of optional user 

data. Both the string and its descriptor must be in read/write storage. 

Return Status 

SS$_N0RMAL The service completed successfully. 

SS$_FILNOTACC No logical link is associated with the channel. 

$QIO (Declaring a Network Name Or Object Number) 

The $QIO system service with a function code of IO$__ACPCONTROL assigns 
a network name or object number to the task, thereby making it eligible to 
process multiple inbound connection requests. You must associate a mailbox 
with the I/O channel. All inbound connection requests are placed in the 
mailbox associated with the channel over which this I/O function is issued. 
The SYSNAM privilege is required to declare a name or object number. 

MACRO programmers should be aware that whenever a logical link is 
established, its device unit number (for example, 18 from _NET18:) should 
be obtained by using the $GETDVI system service, because unit numbers and 
not channel numbers appear in mailbox messages. Use this system service 
call where a single mailbox is being used for many logical links. The unit 
number could be used as a key into a database that keeps track of multiple 
links. 

Format 

$QI0 [efn] ,chan ,func ,[iosb] ,[astadr] .[astprm] ,pl ,p2 


Arguments 

efn Number of the event flag to be set at event completion. 

chan A word containing the channel number associated with the logical link. 

Use the same channel number assigned previously in the SASSIGN 
call. 

func I0$_ACPC0NTR0L 

iosb Address of a quadword I/O status block that will receive the 

completion status. 

astadr Entry point address of the AST routine that executes when the I/O 
operation completes. If specified, the AST routine executes at the 
access mode from which the $QI0 service was requested. 

astprm The AST parameter to be passed to the AST completion routine. 
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pi Address of a quadword descriptor of a 5-byte block consisting of a 

function type (one byte) and a longword parameter. The function type 
is a symbol defined by the SNFBDEF macro in SYS$LIBRARY:LIB.MLB. 
The format of the 5-byte block for declaring a name is 

.BYTE NFB$C_DECLNAME 
.LONG 0 

The format of the 5-byte block for declaring an object number is 

.BYTE NFB$C_DECLOBJ 
.LONG object-number 

The object number is a number reserved for customer use in the range 
of 128 to 255. This 5-byte buffer and its descriptor should be in 
read/write storage. 

p2 Address of a quadword descriptor of the network name (maximum of 

12 characters). This argument is ignored for the DECLOBJ function. 
Both the name and its descriptor must be in read/write storage. 


Return Status 

SS$_NORMAL 

SS$_BADPARAM 

SS$_ILLCNTRFUNC 

SSS—NOMBX 

SS$_NOPRIV 


The service completed successfully. 

One of the QIO parameters has an invalid value. 

The control function is invalid. 

A name or object number is being declared using a 
channel without an associated mailbox. 

The issuing process does not have the SYSNAM 
privilege. 


8.6.2.11 $DASSGN (Terminating a Logical Link) 

The $DASSGN system service terminates all pending operations to send 
and receive data, aborts the logical link immediately, and frees the channel 
associated with that link. Refer to Section 8.5.5.4 for the format of this call, 
its arguments, and possible return status codes. 


8.7 Designing Tasks 

This section contains a command procedure and three user program examples 
designed to perform task-to-task communications over the network. 

The command procedure and the first two user program examples illustrate 
transparent operations. The third user program example illustrates a 
nontransparent operation. 


8.7.1 DCL Command Procedure for Task-to-Task Communication 

As described in Section 8.5, you can write command procedures in DCL 
to execute transparent task-to-task operations. The command procedure 
below, called SHOWBQ.COM, can be used to perform such an operation. 
You can use SHOWBQ.COM for task-to-task communication by entering a 
task-spec-string in a TYPE command. For example: 

$ TYPE TRNTO"BROWN JUNE"::"TASK=SHOWBQ" 
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In this command procedure, SYS$OUTPUT is equated to SYS$NET in user 
mode to allow the SHOW QUEUE image to communicate over the logical 
link by opening SYS$OUTPUT. When the SHOW QUEUE image exits, 
the temporary definition of SYS$OUTPUT is deleted. In other words, only 
one DCL image can use the logical link as the communication path to the 
requester at the other node. 

SHOWBQ.COM 

$ ! 

$ ! This command procedure returns status information about 

$ ! jobs entered in batch queues on the system where it 

$ ! executes. It may be run interactively as a command 

$ ! procedure, submitted as a local or remote batch job, or 

$ ! invoked as a "remote task" to display information about 

$ ! another system. For example: 

$ ! 

$ ! $ (OSHOWBQ 

$ ! $ SUBMIT SHOWBQ 

$ ! $ SUBMIT/REMOTE node::SHOWBQ 

$ ! $ TYPE node::»TASK=SHOWBQ" 

$ • 

$ IF F$M0DE() .EQS. "NETWORK" THEN GOTO NET 
$ SHOW QUEUE/BATCH/BRIEF/ALL 
$ EXIT 
$NET: 

$ DEFINE/USER SYS$OUTPUT SYS$NET 
$ SHOW QUEUE/BATCH/BRIEF/ALL 
$ EXIT 


8.7.2 FORTRAN Program for Task-to-Task Communication 

Example 8-2 is a simple example of VAX FORTRAN transparent 
communication. In the FORTRAN source task that initiates the logical 
link request, you use a standard open statement to specify the remote task to 
which you want to connect. In turn, the remote task issues an open statement 
to complete the logical link connection. A coordinated set of read and write 
operations enable the exchange of information over the link. To terminate 
the connection, the source task executes a close statement to break the logical 
link. When the remote task receives this close statement, it issues a close 
statement, which completes the link termination process. The remainder of 
this section discusses the statements that you would use to develop such an 
application. 
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Example 8-2 FORTRAN Task-to-Task Communication 


PROGRAM TEST3.FOR 
C 

C This program prompts the user for the part number of an item 

C in inventory and responds with the number of units in stock. 

C The information is obtained by communicating with a program 

C (TEST4) on another node that has access to the inventory data. 

C 

C Before running this program, the logical name TASK must be 

C defined to refer to the target program. For example: 

C 

C $ DEFINE TASK "TRNTO:: H "TASK=TEST4""" 

C $ RUN TEST3 

C 

CHARACTER PARTN0*5 
INTEGER PARTCOUNT 

C 

100 FORMAT (/,'$Enter part number: ') 

200 FORMAT (A) 

300 FORMAT (14) 

400 FORMAT ('OInventory for part number ',A,' is: ',14) 

C 

C Establish a logical link with the target task. 

C 

O OPEN (UNIT=1,NAME= ' TASK ' ,ACCESS= ' SEQUENTIAL ' , 

1 F0RM='FORMATTED',CARRIAGECONTROL='NONE 1 .TYPE='NEW') 

C 

C Prompt the user for a part number, send it to the target task, 

C read reply of quantity on hand, and finally display the answer 

C for the user. Repeat the cycle until the user enters 'EXIT' for 

C a part number. 

C 

10 TYPE 100 

ACCEPT 200, PARTNO 
IF (PARTNO .EQ. 'EXIT') GOTO 20 
O WRITE (1,200) PARTNO 
READ (1,300) PARTCOUNT 
TYPE 400, PARTNO, PARTCOUNT 
GOTO 10 
C 

C Disconnect the logical link. 

C 

20 © CLOSE (UNIT=1) 

END 

$ ! TEST4.COM 

$ ! 

$ ! This command procedure executes the program TEST4 after 

$ ! being started by a task-to-task connection request issued 

$ ! by TEST3. 

$ ! 

©$ RUN SYS$L0GIN:TEST4.EXE 
$ EXIT 

PROGRAM TEST4.FOR 
C 

C Test4 is the target program that communicates with TEST3. 

C For each part number received from the source task, the 

C number of units in stock is determined, and this value is 

C returned. 


(Continued on next page) 
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Example 8-2 (Cont.) FORTRAN Task-to-Task Communication 


c 

C To complete the logical link with its initiator, this program 

C uses the logical name SYS$NET as the file specification in an 

C open statement. 

C 

CHARACTER PARTN0*5 
INTEGER PARTCOUNT 
C 

100 FORMAT (A) 

200 FORMAT (14) 

C 

C Complete the logical link connection. 

C 

© OPEN (UNIT=1.NAME='SYS$NET',ACCESS^'SEQUENTIAL', 

1 F0RM=■FORMATTED',CARRIAGECONTROL- 1 NONE',TYPE=•OLD•) 

C 

C Process requests until end-of-file is reached. (This is the 

C error condition returned when the source task breaks the 

C logical link connection.) 

C 

10 © READ (1,100,END=20) PARTNO 

C 

C Perform appropriate processing to obtain the part count value 

C and transmit this back to the source task. 

C 

CALL INSTOCK (PARTNO.PARTCOUNT) 

© WRITE (1,200) PARTCOUNT 
GOTO 10 

C 

C Disconnect the logical link. 

C 

20 © CLOSE (UNIT=1) 

END 


Notes on Example 8-2 

© The source task, TEST3, requests a logical link connection to the target 
task, TEST4. 

© When the remote node receives a connection request, the command 

procedure TEST4.COM is executed. This command procedure must reside 
in the default directory associated with the account being accessed. 
TEST4.COM contains a RUN statement that causes the program 
TEST4.EXE to be executed. 

© TEST4 completes the logical link connection through SYS$NET. Note that 
the unit numbers in the source and target programs need not be the same. 

© TEST3 and TEST4 send and receive data messages. 

© TEST3 disconnects the logical link and thereby terminates the 
communication process. 

Because DECnet-VAX translates system-dependent language calls into the 
same set of messages that permit task-to-task communication, any task 
programmed in VAX MACRO or one of the higher-level languages can 
communicate with a remote task programmed in the same or a different 
language. More specifically, for communication between tasks that run on 
VAX/VMS nodes, the language in which you access the network has no 
effect on the communication process. The VAX FORTRAN source task in 
Example 8-2 could just as easily communicate with a MACRO task on node 
TRNTO. 
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8.7.3 MACRO Program for Transparent Task-to-Task Communication 

Example 8-3 illustrates the use of system service calls for transparent 
communication. TRANA is a MACRO source task on the local node that 
communicates with a target task, TRANB, on node TRNTO. The source task 
sends a connection request to the remote node whereupon the target task is 
started by the command file TRANB.COM. Once the logical link connection 
is made, the source task sends a message to the target task, which in turn 
responds with a message and then waits for additional message traffic. The 
source task drives the communication process. Once the source task receives 
a response from the target task, it disconnects the link and exits, which causes 
the target task to exit also, thereby terminating the communication process. 

Example 8-3 Transparent Communication Using System 
Services 


.TITLE TRANA - SOURCE TASK USING TRANSPARENT I/O 
.IDENT /VI.0/ 

.SBTTL WRITABLE.DATA 

.PSECT TRANA$DATA SHR,NOEXE,RD,WRT,BYTE 


NETCHAN:.BLKW 1 
IOSBUF: .BLKQ 1 

TARGET: .ASCID /TRNTO"MALIK KARL"::"TASK=TRANB"/ 


Network channel 
I/O status block 
Task-spec (and descriptor) 


SENDMSG:.ASCII /SEND THIS STRING TO TRANB/ 
SENDMSG_SIZ=.-SENDMSG 
RECVMSG:.BLKB 512 
RECVMSG_SIZ=.-RECVMSG 


Output buffer 
Output buffer size 
Input buffer 
Input buffer size 


.SBTTL MAIN 

.PSECT TRANA$CODE NOSHR,EXE,RD,NOWRT,BYTE 

.ENTRY START,~M<> ;Entry point from exec 


Request a logical link to the target task and assign an I/O channel. 


$ASSIGN_S - 

DEVNAM=VT TARGET,- 
CHAN=VT NETCHAN 
BLBC RO,EXIT 

Send a message to the target task. 

$QIOW_S - 

EFN=#1,- 

CHAN=W~NETCHAN,- 
FUNC=S“#IO$_WRITEVBLK,- 
IOSB=VT IOSBUF.- 
P1=VTSENDMSG,- 
P2=S~#SENDMSG_SIZ 
BLBC RO,EXIT 

MOVZWL vr IOSBUF.RO 

BLBC RO,EXIT 


; Assign a channel to target task 
; Address of device name descriptor 
; Address to receive channel number 
; Branch on failure 


Issue transmit request 
Use local event flag number 1 
Use assigned channel 
Write virtual block 
Address of I/O status block 
Address of output buffer 
Size of output buffer 
Branch on failure 
Get completion status 
Branch on failure 


(Continued on next page) 
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Example 8-3 (Cont.) Transparent Communication Using 

System Services 


; Receive a message from the target task. 

$QI0W_S - ; 

EFN=#1,- ; 

CHAN=VTNETCHAN, - ; 

FUNC=S~#IO$_READVBLK,- ; 

I0SB=W~I0SBUF,- ; 

P1=W~RECVMSG,- ; 

P2=#RECVMSG_SIZ ; 

BLBC RO.EXIT ; 

MOVZWL W~IOSBUF.RO ; 

BLBC RO.EXIT ; 

; Abort the logical link. 

$DASSGN_S - ; 

CHAN=W~NETCHAN ; 

; Exit with status (in R0). 

EXIT: $EXIT_S R0 ; 

.END START ; 


Issue receive request 

Use local event flag number 1 

Use assigned channel 

Read virtual block 

Address of I/O status block 

Address of input buffer 

Size of input buffer 

Branch on failure 

Get completion status 

Branch on failure 


Deassign the channel 

Address of word containing channel number 

Exit with status to be displayed 
on error condition 

Image transfer address 


.TITLE TRANB - TARGET TASK USING TRANSPARENT I/O 
.IDENT /VI.0/ 

.SBTTL WRITABLE.DATA 

.PSECT TRANB$DATA SHR.NOEXE.RD.WRT.BYTE 


NETCHAN:.BLKW 1 
IOSBUF: .BLKQ 1 
RECVMSG:.BLKB 512 
RECVMSG_SIZ=.-RECVMSG 
LOGNAM: .ASCID /SYS$NET/ 
SENDMSG:.ASCII /REPLY TO TRANA/ 
SENDMSG_SIZ=.-SENDMSG 


Network channel 

I/O status block 

Input buffer 

Input buffer size 

Logical name and descriptor 

Output buffer 

Output buffer size 


.SBTTL MAINLINE 

.PSECT TRANB$CODE NOSHR.EXE.RD.NOWRT.BYTE 

.ENTRY START,~M<> ;Entry point from exec 


Complete the logical link connection (that TRANA requested). 


$ASSIGN_S - 

DEVNAM=W~LOGNAM,- 
CHAN=VT NETCHAN 
BLBC RO.EXIT 

LOOP: 


Assign channel to SYS$NET 
Descriptor of SYS$NET 
Store channel number 
Branch on failure 


Receive message from source task. 

$QI0W_S - 

EFN=#1,- 

CHAN =VT NETCHAN , - 
FUNC=S~#IO$_READVBLK,- 
I0SB=W“IOSBUF,- 
P1=W~RECVMSG,- 
P2=#RECVMSG_SIZ 
BLBC RO.EXIT 

MOVZWL W~I0SBUF.R0 
CMPW S~#SS$_ABORT,RO 

BEQL DONE 

BLBC RO.EXIT 


Issue receive request 

Use local event flag number 1 

Use assigned channel 

Read virtual block 

Address of I/O status block 

Address of input buffer 

Size of input buffer 

Branch on failure 

Get completion status 

Was logical link aborted? 

Branch if yes 

Branch on failure 




(Continued on next page) 
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Example 8-3 (Cont.) Transparent Communication Using 

System Services 


Send message to source task. 

$QI0W_S - 

EFN=#1,- 

CHAN=VTNETCHAN,- 
FUNC=S“#IO$_WRITEVBLK,- 
I0SB=W“I0SBUF,- 
P1=W“SENDMSG,- 
P2=S“#SENDMSG_SIZ 
BLBC RO,EXIT 

MOVZWL VTIOSBUF.RO 
BLBC RO.EXIT 

BRB LOOP 


Issue transmit request 
Use local event flag number 1 
Use assigned channel 
Write virtual block 
Address of I/O status block 
Address of output buffer 
Size of output buffer 
Branch on failure 
Get completion status 
Branch on failure 
Reissue the read 


; Logical link was aborted. 

DONE: $DASSGN_S - 

CHAN=W“NETCHAN 

; Exit with status (in RO). 

EXIT: $EXIT_S RO 

.END START 


Deassign the channel 
Address of channel number 

Exit with status to be displayed 
on error condition 
Image transfer address 


8.7.4 MACRO Program for Nontransparent Task-to-Task Communication 

Example 8-4 illustrates the use of several of these system service calls for 
nontransparent task-to-task communication. CONNECT is a nontransparent 
MACRO source task on the local node that communicates with a 
nontransparent target task, DECLARNAM, on node DENVER. This example 
is similar to Example 8-2, except that the source task here uses an NCB 
and performs a nontransparent assign operation to establish communication 
with the target task. DECLARNAM is a nontransparent target task that has 
declared a name (that is, it is eligible to receive multiple inbound connection 
requests). In addition, it also uses a mailbox to receive network status 
notifications. Neither task performs useful functions. They are presented 
here only to illustrate various nontransparent functions. 
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Example 8-4 Nontransparent Communication Using System Services 


DECLARNAM 


.TITLE DECLARNAM- NONTRANSPARENT EXAMPLE (WITH DECLARED NAME) 
.IDENT /VI.0/ 


.SBTTL READONLY.DATA 
.PSECT DECLARNAM$RDDATA 

INFBDEF 

IDIBDEF 

DEVDESC:.ASCID /.NET:/ 

MAXMSG: .LONG 128 

BUFQUO: .LONG 128 

MBXDESC:.ASCID /DECLARMBX/ 
MAXLINKS=128 
BUFFER.SIZE=64 


SHR,NOEXE,RD,NOWRT.BYTE 


Pseudo-device and descriptor 
Maximum message size 
Buffer quota 

Mailbox lognam and descriptor 
Maximum number of logical links allowed 
Size of input buffer to accept 
; messages 


.SBTTL 

READWRITE.DATA 



.PSECT 

DECLARN AM$RWDATA 

SHR,NOEXE,RD,WRT,BYTE 

NAMEDESC: 



Declared name & descriptor 

.ASCID 

/DECLARNAM/ 



DCL.CHAN: 




.BLKW 

1 


Word to receive declared name channel number 

DEV.CHAN: 




.BLKW 

1 


Word to receive device channel number 

MBX.CHAN: 




.BLKW 

1 


Word to receive mailbox channel number 

MBXMSG: .BLKB 

128 


Mailbox buffer 

IOSB: .BLKQ 

1 


I/O status block 

AST.IOSB: 



I/O status block for AST 

.BLKQ 

1 



NCBDESC:.LONG 

100 


Network control block descriptor 

.LONG 

NCB 



NCB: .BLKB 

100 


Network control block 

NFBDESC:.LONG 

5 


Network function block descriptor 

.LONG 

NFB 



NFB: .BYTE 

NFB$C_DECLNAME 


Network function block 

.LONG 

0 



PRILEN: .WORD 

0 


Length of buffer for $GETCHAN info 

PRIBUF: .LONG 

128 


Descriptor of $GETCHAN buffer 

.LONG 

PBUF 



PBUF: .BLKB 

128 


Buffer to receive $GETCHAN info 

COUNT: .BLKL 

1 


Number of table entries 

CHAN.LIST: 



Channel number list 

.BLKW 

MAXLINKS 



UNIT.LIST: 



Unit number list 

.BLKW 

MAXLINKS 



IOSB.LIST: 



Read message I/O status block list 

.BLKQ 

MAXLINKS 



BUFFERS:.BLKB 

MAXLINKS * BUFFER.SIZE 


Input buffers to put message 

LIST: 



List of pointers to input buffers 


OFFSET = 0 
.REPT MAXLINKS 
.ADDRESS BUFFERS + OFFSET 
OFFSET = OFFSET + BUFFER.SIZE 
.ENDR 

.SBTTL MAIN 


(Continued on next page) 
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Example 8-4 (Cont.) Nontransparent Communication Using 

System Services 


+ 


This program demonstrates the use of a declared name to allow multiple 
inbound connection requests. It is included for illustrative purposes 
and is not intended to perform any useful work. In particular, nonnetwork 
code is kept to a minimum (note for example, that all errors result in 
program termination, which is an inappropriate procedure for most applications). 


.PSECT DECLARNAM$CODE NOSHR,EXE.RD.NOWRT,BYTE 

.ENTRY START,~M<> ; Main entry point 


Create a temporary mailbox with the logical name DECLARMBX. 


$CREMBX_S - 

CHAN=VT MBX_CHAN,- 
MAXMSG=W~MAXMSG, - 
BUFQU0=W~BUFQU0,- 
LOGNAM=VTMBXDESC 


Address of word to put mailbox channel 
Address of longword with maximum message size 
Address of longword with buffer quota 
Address of descriptor of mailbox lognam 


BLBC RO,EXITS 


Error if LBC 


Assign a channel to a NET device and associate the mailbox with it. 


$ASSIGN_S - 

DEVNAM=VT DEVDESC,- 
CHAN=VTDCL_CHAN, - 
MBXNAM=VTMBXDESC 


Issue $ASSIGN system service request 
Address of descriptor of NET device 
Address of word to put channel number 
Address of descriptor of mailbox logical name 


BLBC RO,EXITS 


Error if LBC 


Declare a network name. 

$QI0W_S - 

CHAN=VT DCL.CHAN,- 
FUNC=#IO$_ACPCONTROL,- 
I0SB=VTI0SB,- 
P1=W~NFBDESC,- 
P2=#NAMEDESC 

BLBC RO.EXITS 

MOVZWL W~IOSB.RO 
BLBC RO.EXITS 


Issue declare name request 
Use assigned channel 
ACP QIO 

Address of I/O status block 
Address of NFB descriptor 
Address of declared name descriptor 

Error if LBC 
Get the I/O status 
Error if LBC 


; Issue an asynchronous read to the mailbox. 

BSBW READ_MBX ; Set up mailbox read AST 

I 

; Now, go to sleep until someone writes to our mailbox. 

$HIBER_S ; zzzzzzz. 

EXITS: $EXIT_S RO ; Exit with status 

.SBTTL MAILBOX.AST 

.ENTRY MAILBOX.AST,'‘MO ; Entry point for AST routine 

; + 

; AST routine to examine the mailbox message code 
; and determine the appropriate action. 

MOVZWL W~AST_I0SB,R0 ; Get asynchronous I/O completion status 

BLBC RO,EXITS ; Branch on failure 

CASEB W~MBXMSG,#MSG$_ABORT,#MSG$_NETSHUT-MSG$_ABORT 


(Continued on next page) 
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DISP.TAB: 

.WORD ABORT-DISP.TAB 
.WORD CONFIRM-DISP.TAB 
.WORD CONNECT-DISP.TAB 
.WORD DISCON-DISP.TAB 

.WORD EXIT-DISP.TAB 
.WORD INTMSG-DISP.TAB 

.WORD PATHLOST-DISP.TAB 
.WORD PROTOCOL-DISP.TAB 
.WORD REJECT-DISP.TAB 
.WORD THIRDPARTY-DISP.TAB 
.WORD TIMEOUT-DISP.TAB 
.WORD NETSHUT-DISP.TAB 

BRB EXITS 

CONNECT: 

BSBW CONNECT.ACCEPT 

CMPW #I0$_ACCESS!IO$M_ABORT,R4 

BEQL 10$ 


BSBW READ.CHAN 


10$: BSBB READ.MBX 

RET 

DISCON: 

ABORT: 

EXIT: 

PATHLOST: 

PROTOCOL: 

THIRDPARTY: 

TIMEOUT: 

BSBW DISCONNECT 

BSBB READ.MBX 

RET 

NETSHUT: 

$WAKE_S 

RET 


INTMSG: 

REJECT: 

CONFIRM: 

BSBB READ.MBX 
RET 

.SBTTL READ.AST 
.ENTRY READ.AST,“M<> 


Fall through on mailbox message out of range 
Unknown mailbox message encountered 

Go accept the connect request 
Was the connect request rejected? 

If rejected then do not issue the 
read 

Issue a read on the channel we 
just confirmed 

Requeue the mailbox read AST 
Return control to main program 


Go disconnect the link 
Requeue the mailbox read AST 
Return control to main 

The network is shutting down 
Wake the main program so that 
it will exit 

Ignore interrupt messages for 
this example 


Requeue the mailbox read AST 
Return control to main 

Entry point for AST routine 


; AST routine to check the completion status of the read and to process 
; the message received. 


MOVL 4(AP),R8 

MOVQ W~I0SB_LIST[R8],R0 

CMPW #SS$_LINKAB0RT,R0 
BEQL 10$ 

CMPW ##SS$LINKDISCON,RO 

BEQL 10$ 

BLBC RO,EXITS 


Get the index to the lists 
Get the I/O completion status 
Did the link go away? 

If EQL then ignore 

Did the partner disconnect the link? 
If EQL then ignore 
If LBC then error 


(Continued on next page) 
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; Message is received and written into the buffer pointed to by 
; BUF_ADR_LIST[Rl]. Useful code could be inserted here to process 
; the message. When complete, reissue the read on the channel and 
; then go back to point where interruption occurred. 

MOVW W~CHAN_LIST[R8],R3 ; Get the channel number 

BSBB READ_CHAN ; Reissue the read 

10$: RET ; Return from AST routine 


.SBTTL SUBROUTINES 


+ 


Subroutine to issue an asynchronous read to the mailbox with an AST. 


READ.MBX: 

$QI0_S - 

CHAN=W~MBX_CHAN,- 
FUNC=#IO$_READVBLK,- 
I0SB=W~AST_I0SB,- 
ASTADR=W~MAILBOX_AST,- 
Pi=W~MBXMSG,- 
P2=W~MAXMSG 
BLBS R0,10$ 

BRW EXITS 

10$: RSB 


Issue read with AST 
Use assigned mailbox channel 
Read virtual block 
Address of I/O status block 
Address of AST routine 
Address of input buffer 
Length of input buffer 
Error if LBC 
Branch (failure) 

Return from subroutine 


+ 

Subroutine to issue an asynchronous read to the channel with an AST. 


READ_CHAN: 



$QI0_S 


Issue read with AST 



CHAN=R3,- 

Use channel we just confirmed 



FUNC=#IO$_READVBLK,- 

Read virtual block 



I0SB=W~I0SB_LIST[R8] 

Address of 1/0 status block 



ASTADR=W~READ_AST,- 

Address of AST routine 



ASTPRM=R8,- 

Store index as AST parameter 



P1=W~®BUF_ADR_LIST[R8] 

Address of input buffer 



P2=#BUFFER_SIZE 

Length of input buffer 


BLBS 

RO,10$ 

Error if LBC 


BRW 

EXITS 

Branch (failure) 

10$: 

RSB 


Return from subroutine 


.PAGE 



; Subroutine to 

accept the connect request and add the channel and unit 

; numbers to the lists 



CONNECT.ACCEPT: 

MOVAB W~MBXMSG+4,R9 
MOVZBL (R9)+,R8 
ADDL2 R8.R9 
MOVZBL (R9)+,R8 
M0VC3 R8.(R9),W~NCB 
MOVL R8,W~NCBDESC 


Get address of device name count 

Get byte count of device name string 

Skip over the string 

Get byte count of info string 

Put the NCB in address NCB 

Update the NCB descriptor 


Make sure we haven't reached maximum links. 


CMPL 

BGTR 

MOVW 

MOVZWL 

BRB 


#MAXLINKS,W~COUNT 

5$ 

W~DCL_CHAN,R3 
#I0$_ACCESS!I0$M_AB0RT 
25$ 


; Have maximum number of links been reached? 
; If not, then assign a channel to NET 
; Use the original channel 
R4;Set up with connect reject code 
; Go make the reject 


(Continued on next page) 
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5$: 

$ASSIGN. 

_s - 

Assign a channel to the task 



DEVNAM=W~DEVDESC,- 

Address of NET descriptor 



CHAN=W~DEV_CHAN,- 

Channel number 



MBXNAM=W~MBXDESC 

Associate the mailbox with new network device 


BLBS 

RO,10$ 

If LBC then error 


BRW 

EXITS 

Branch (failure) 

; Now, 

get the channel and unit numbers and put them in their respective lists. 

10$: 

$GETCHN_ 

.s - 

Issue get chan system service 



CHAN=W~DEV_CHAN,- 

Address of word containing channel number 



PRILEN=W~PRILEN,- 

Address of word to put length returned 



PRIBUF=W“PRIBUF 

‘ Address of descriptor of buffer 


BLBS 

RO,19$ 

If LBC then error 


BRW 

EXITS 

Branch (failure) 

19$: 

CLRL 

R8 

Initialize the index 

20$: 

TSTW 

W~CHAN_LIST[R8] 

Is it empty? 


BEQL 

22$ 

Branch if an empty slot is found 


A0BLEQ 

W~COUNT.R8,20$ 

Increment the index and try again 


BRW 

EXITS 

No empty slots? 

22$: 

MOVW 

W~DEV_CHAN, W~CHAN_LIST [R8];Put the chan number in the chan list 


MOVW 

W~PBUF+DIB$W_UNIT,W~UNIT_LIST[R8] ; Put unit number in unit list 


INCL 

W~COUNT ; 

; Increment the number of entries 

; Issue the connect confirm QIO. 



MOVW 

W~DEV_CHAN,R3 

Set up with address of assigned chan 


MOVZWL 

S~#I0$_ACCESS,R4 

Set up with connect accept function code 

25$: 

$QI0W_S 

- 

Issue connect confirm/reject request 



CHAN=R3, - 

Use assigned channel 



FUNC=R4, - 

Request a logical link 



I0SB=W~I0SB, - 

Address of I/O status block 



P2=#NCBDESC 

Address of NCB descriptor 


BLBS 

RO,30$ 

If LBC then error 


BRW 

EXITS 

Branch (failure) 

30$: 

MOVZWL 

W~I0SB,R0 

Get I/O completion status 


BLBS 

RO,40$ 

If LBC then error 


BRW 

EXITS 

Branch (failure) 

40$: 

RSB 


Return from subroutine 

; + 

; Subroutine to 

disconnect a channel and 

remove its entry from the lists. 

DISCONNECT: 




MOVZWL 

W~MBXMSG+2,RO 

Get the unit number 


CLRL 

R8 

Initialize the index 

5$: 

CMPW 

W~UNIT_LIST[R8],R0 

Locate the unit number in the list 


BEQL 

10$ 

If EQL then success 


AOBLEQ 

W~COUNT,R8,5$ 

Increment the index and try again 

10$: 

MOVZWL 

W~CHAN_LIST[R8],R9 

Channel number is located 


$DASSGN. 

_S - 

Deassign the channel 


• 

CHAN=R9 

Channel number 


BLBS 

RO.20$ 

If LBC then error 


BRW 

EXITS 

Branch (failure) 


The channel has been deassigned. Remove the entries from the unit and 
channel lists. 
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20$: 


DECL 

W*COUNT 

J 


CLRW 

W~CHAN_LIST[R8] 

j 


CLRW 

RSB 

W~UNIT_LIST[R8] 

; 


.END 

START 

; 

CONNECT 


.TITLE 

.SBTTL 

CONNECT - ISSUE 
READONLY.DATA 

A CONNECT 


.PSECT 

CONNECT$RDDATA 

SHR,NOEXE 


Decrement the number of entries 
Clear the channel list entry 
Clear the unit list entry 

Return from subroutine 
Image transfer address 

REQUEST TO DECLAR (DECLARED NAME) 
RD,NOWRT,BYTE 


DEVDESC:.ASCID /.NET:/ 
MAXMSG: .LONG 64 

BUFQUO: .LONG 64 


Pseudo-device and descriptor 
Largest size mailbox message allowed 
Mailbox quota 


.SBTTL READWRITE.DATA 

.PSECT CONNECT$RWDATA SHR,NOEXE,RD,WRT,BYTE 


DEV.CHAN: 

.BLKW 1 ; Word to receive device channel number 

MBX.CHAN: 



.BLKW 

1 

; Word to receive mailbox channel number 

MBXMSG: 

. BLKB 

64 

; Mailbox buffer 

IOSB: 

. BLKQ 

1 

; I/O status block 

NCBDESC: 

.LONG 

NCB.SIZE 

; Network connect block and descriptor 


.LONG 

NCB 


NCB: 

.ASCII 

7DENVER::? 

; Node-spec string 


.ASCII 

?"(TASK=DECLAR/? 

; Task-spec string (declared name) 


.WORD 

0 

; Must be zero 


.ASCII 

/"/ 

; End of NCB 

NCB_SIZE= 

=.-NCB 


; Size of NCB 


.SBTTL 

MAIN 



This program demonstrates how to make a connection request to a task 
that has declared a network name. It does not perform any useful work 
but does serve to illustrate DECnet nontransparent I/O. 

.PSECT C0NNECT$C0DE N0SHR,EXE,RD,NOWRT,BYTE 

.ENTRY START,~M<> 

Use the Run-Time Library routine, LIB$ASN_WTH_MBX to establish 
a communication path to DECnet software in preparation for 
nontransparent I/O operations. 


This routine will create a temporary mailbox and assign a channel to it and 
assign a channel to .NET: and associate the temporary mailbox with it. 


The mailbox can be used to obtain supplementary information from 
DECnet software about logical link operations. 


PUSHAW 

W~MBX.CHAN 

PUSHAW 

W“DEV_CHAN 

PUSHAL 

W~BUFQU0 

PUSHAL 

W~MAXMSG 

PUSHAQ 

W~DEVDESC 

CALLS 

#5,LIB$ASN_WTH_MBX 

BLBS 

RO,10$ 

BRW 

EXITS 


Address to receive mailbox channel number 
Address to receive device channel number 
Mailbox quota 

Largest size mailbox message allowed 
Address of device name descriptor 
Assign channel and associate mailbox 
If LBC then error 
Branch (failure) 
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Request a logical link to the remote task 


10$: $QI0W_S - 

CHAN=VT DEV.CHAN,- 
FUNC=#IO$_ACCESS,- 
I0SB=W~I0SB,- 
P2=#NCBDESC 

Issue connect initiate request 

Use assigned channel 

Request a logical link 

Address of I/O status block 

Address of NCB descriptor 

BLBC RO,EXITS 

MOVZWL VTIOSB.RO 

BLBC RO,EXITS 

If LBC then error 

Get I/O completion status 

If LBC then error 


+ 

Established a logical link with DECLARNAM. Useful code could be inserted 
here before continuing with the disconnect. 

Disconnect the logical link by deassigning the channel. 


$DASSGN_S - 

CHAN=VTDEV_CHAN 

BLBC RO.EXITS 

EXITS: $EXIT_S RO 

Issue the deassign request 

Address of word containing channel number 

If LBC then error 

Exit with status to be displayed 
on error condition 

.END START 
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9 File Operations in a Heterogeneous Network 
Environment 


This chapter contains material to assist you in using DECnet-VAX Version 
4 to initiate remote file operations in a heterogeneous network environment. 
Restrictions on using DCL commands and RMS service calls to access files on 
the following types of remote systems are discussed in this chapter: 

VAX/VMS to IAS 

VAX/VMS to P/OS 

VAX/VMS to RSTS/E 

VAX/VMS to RSX using RMS-based FAL 

VAX/VMS to RSX using FCS-based FAL 

VAX/VMS to RT-11 

VAX/VMS to TOPS-IO 

VAX/VMS to TOPS-20 

VAX/VMS Version 4 to VAX/VMS Version 3 

VAX/VMS Version 4.4 to previous VAX/VMS version 

The chapter is organized by operating system type: one section for each 
heterogeneous system with which your VAX/VMS system running DECnet- 
VAX Version 4 may wish to communicate. Each section describes differences 
in file system operation between the two systems and constraints on the use 
of VAX/VMS file processing commands. The restrictions on the remote file 
operations you can perform from a VAX/VMS Version 4 node to a particular 
heterogeneous node result from file system design differences and DECnet 
implementation restrictions between the systems. 

Specifically, the appropriate section for each remote system itemizes the 
VAX Record Management System (RMS) features that are supported between 
DECnet-VAX Version 4 systems, but are not supported when accessing files 
on the heterogeneous system. The section also discusses limitations on the 
DIGITAL Command Language (DCL) commands that you can use when 
communicating with the remote node. Throughout this chapter comments are 
provided to help you handle the differences in file system design. 

The most recent version of DECnet used by each heterogeneous system is 
represented in this chapter. 


9.1 General DECnet-VAX Restrictions 

This section is a brief summary of VAX RMS features that are not supported 
by DECnet-VAX for remote file access. The list is not complete; it is meant 
only to highlight the more important differences between local and remote file 
access capabilities. For more complete information on this subject, refer to the 
description of the various RMS control blocks in the VAX Record Management 
Services Reference Manual. 

• The following VAX RMS service calls are not supported for network use: 
SENTER SNXTVOL SREMOVE 

• The Terminal XAB is not supported for network operations; it is ignored. 
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• New fields in the Protection XAB for VAX/VMS Version 4 to support 
access control lists are ignored for network operations. 

• Only one data stream per open file is allowed. That is, the multistream 
(MSE) bit option of the file sharing (SHR) field of the FAB is not supported 
for network use. 

• Access to files on magnetic tapes mounted on a remote VAX/VMS system 
is not supported. You can, however, copy files from a local magnetic tape 
to disk on a remote node. 

• When multiple Allocation XABs are linked to the FAB, they must be in 
ascending order by area number (AID field). Similarly, when multiple 
Key Definition XABs are used, they must be in ascending order by key of 
reference (REF field). 

• File protection information may not be completely preserved if the two 
nodes do not fully support each other's protection attributes. 

An example of this incompatibility occurs between RSX-11M/RSX-11M- 
PLUS and VAX/VMS systems. Although both systems represent their 
protection masks as RWED, RSX-11M/RSX-11M-PLUS interprets that 
as Read, Write, Extend, and Delete, while VAX/VMS interprets RWED as 
Read, Write, Execute, and Delete. This results in the "E" protection field 
being unmappable between these two systems. 


9.2 VAX/VMS to IAS Network Operation 

This section pertains to a VAX/VMS node communicating with an IAS node 
running DECnet-IAS V3.0. The discussion focuses on file operations initiated 
from the VAX/VMS node to access remote files by means of the FAL at the 
IAS node. 


9.2.1 File System Constraints 

The restrictions described below are related to incompatible features in file 
system design between the two systems. 


9.2.1.1 


File Formats and Access Modes 

The following types of files and access methods are not supported by 
VAX/VMS when communicating with an IAS node: 


File organizations and record formats: 

Sequential Stream (STM) 

Stream_CR (STMCR) 

Stream_LF (STMLF) 

Variable with fixed control (VFC) where fixed header size is 
not 2 bytes 

Relative All formats 

Indexed All formats 


• Record attributes: 

Print file carriage control (PRN) 
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• File access modes: 

Random access by relative record number 
Random access by key value 
Random access by record file address 
Block I/O 

You can copy a sequential file in VFC format from a VAX/VMS node to an 
IAS node provided that the file has a 2-byte fixed header with a carriage 
control attribute other than print file. To transfer a file having print file 
carriage control, such as a VAX/VMS batch log file, use the command 

$ CONVERT/FDL=VAR.FDL input-file output-file 

where the FDL control file VAR.FDL contains 

FILE 

ORGANIZATION sequential 

RECORD 

FORMAT variable 

CARRIAGE.CONTROL carriage.return 

The CONVERT command and associated FDL control file will transform the 
input file to variable-length format with implied carriage control and copy it 
to the remote node according to the output file specification. 


9.2.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two VAX/VMS nodes, 
are not supported between a VAX/VMS node and an IAS node: 

• VAX RMS service calls: 

$DELETE SDISPLAY $EXTEND $FIND 

$FREE $READ $RELEASE SRENAME 

SREWIND SSPACE STRUNCATE SUPDATE 

SWRITE 

• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP field 
DEQ (default extend quantity) field 


9.2.1.3 File Specifications 

The general format of a file specification for naming a file on a remote IAS 
system is 

node::device:[directory]name.type;version 

The following are major differences in syntax between file specifications used 
on IAS and on VAX/VMS: 

• IAS does not support dollar sign ($) and underscore (_) characters in file 
name components. 

• IAS does not recognize the percent sign (%) as a valid wildcard character. 
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• The directory component of an IAS file specification cannot be a named 
directory list, such as [A.B.C]; it must be in UIC (user identification code) 
format, such as [100,3]. 

• The file name component has a maximum length of nine characters and 
the file type cannot exceed three characters. IAS systems will return an 
error if you specify a longer file name or file type. 

• IAS uses octal version numbers in file specifications whereas VAX/VMS 
uses decimal version numbers. 


9.2.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the network, the 
following are not supported between VAX/VMS and an IAS node: 

• ANALYZE/RMS-FILE 

• BACKUP 

• OPEN/WRITE 

• RENAME 


9.2.2.1 


9.22.2 


APPEND 

In using the APPEND command, you are limited to appending one local 
input file to the output file residing on the IAS node. 


COPY 

The /EXTENSION and /PROTECTION qualifiers for the COPY command 
are not supported and will be ignored if specified. 

File creation date and time information is not preserved on a file copy 
operation to an IAS node where wildcards are used in the output file 
specification. Instead, the current date and time is used as the file creation 
date and time. 


Because the IAS system uses octal version numbers in file specifications, an 
attempt to copy a file with a version number containing an 8 or 9 is rejected 
by the remote system, as shown in the following example: 

$ COPY A.DAT;9 IAS::*.* 

'/.COPY-E-OPENOUT, error opening _IAS: :A.DAT;9 as output 
-RMS-F-FNM, error in file name 


There are two ways to circumvent this problem. You can either specify an 
appropriate octal version number in the output file specification, or you can 
specify a null or zero version number in the output file specification to force 
highest version number processing on the remote node. This latter technique 
is particularly useful when several files are copied with one DCL command. 
For example: 


$ COPY A.DAT;9 
$ COPY B.DAT;28 
$ COPY B.DAT;28 
$ COPY *.DAT 


IAS::A.DAT;11 
IAS: 

IAS::*.*;0 
IAS::*.*;0 
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9.3 VAX/VMS to P/OS Network Operation 

This section pertains to a VAX/VMS node communicating with a P/OS 
node running DECnet-PRO VI.0. The discussion focuses on file operations 
initiated from the VAX/VMS node, to access remote files by means of the 
FAL at the P/OS node. 


9.3.1 File System Constraints 

The restrictions described below are related to incompatible features in file 
system design between the two systems. 


9.3.1.1 File Formats and Access Modes 

The following types of file and record attributes are not supported by 
VAX/VMS when communicating with a P/OS node: 

• File organizations and record formats: 

Sequential Stream_CR (STMCR) 

Stream_LF (STMLF) 

Indexed All prologue 3 formats 

With 64-bit binary (BN8) key types 
With 64-bit integer (IN8) key types 

With descending key types (DSTG, DIN2, DBN2, DIN4, 
DBN4, DIN8, DBN8, DPAC) 

• Record attributes: 

(Record attributes are compatible) 

• File access modes: 

(Modes are compatible) 


9.3.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two VAX/VMS nodes, 
are not supported between a VAX/VMS node and a P/OS node: 

• VAX RMS service calls: 

SRELEASE 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP field 
SCF (submit command file) bit of FOP field 
SPL (spool file) bit of FOP field 
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9.3.1.3 File Specifications 

The general format of a file specification for naming a file on a remote P/OS 
system is: 

node::device:[directory]name.type;version 

The following are major differences in syntax between file specifications used 
on P/OS and VAX/VMS: 

• P/OS does not support dollar sign ($) and underscore (_) characters in 
file name components. 

• The directory component in a P/OS file specification cannot be a named 
directory list, such as [A.B.C]; it can be a single directory name, such 

as [USERFILES], or it can be expressed in UIC (user identification code) 
format, such as [15,1]. 

• The file name component has a maximum length of nine characters and 
the file type cannot exceed three characters. P/OS systems will return an 
error if you specify a longer file name or file type. 


9.3.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the network, the 
following are not supported between VAX/VMS and a P/OS node: 

• OPEN/WRITE 

• PRINT/REMOTE 

• SUBMIT/REMOTE 


9.4 VAX/VMS to RSTS/E Network Operation 

This section pertains to a VAX/VMS node communicating with a RSTS/E 
node running DECnet/E V3.0. The discussion focuses on file operations 
initiated from the VAX/VMS node, to access remote files by means of the 
FAL at the RSTS/E node. 


9.4.1 File System Constraints 

The restrictions described below are related to incompatible features in file 
system design between the two systems. 


9.4.1.1 File Formats and Access Modes 

The following types of file and access methods are not supported by 
VAX/VMS when communicating with a RSTS/E node: 

• File organizations and record formats: 

Sequential Stream_CR (STMCR) 

Stream_LF (STMLF) 
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Indexed All prologue 3 formats 

With 64-bit binary (BN8) key types 
With 64-bit integer (IN8) key types 

With descending key types (DSTG, DIN2, DBN2, DIN4, 
DBN4, DIN8, DBN8, DPAC) 


• Record attributes: 

(Attributes are compatible) 

• File access modes: 

Random access by key value 
Random access by record file address 

DECnet/E does not support record mode access to indexed files; it supports 
only block I/O access to indexed files. 

Note that an attempt to access an indexed file located on a RSTS/E node 
in record mode will result in an RMS-F-BUG—DAP error instead of an 
RMS-F-SUPPORT error. 


9.4.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two VAX/VMS nodes, 
are not supported between a VAX/VMS node and a RSTS/E node: 

• VAX RMS service calls: 

SDISPLAY SEXTEND $FREE $RELEASE 

SRENAME SSPACE STRUNCATE 

• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP field 
DEQ (default extend quantity) field 


9.4.1.3 File Specifications 

The general format of a file specification for naming a file on a remote 

RSTS/E system is 

node::device:[directory]name.type 

The following are major differences in syntax between file specifications used 

on RSTS/E and on VAX/VMS: 

• RSTS/E does not support dollar sign ($) and underscore (_) characters in 
file name components, except for the special use of the dollar sign at the 
start of a file name. 

• RSTS/E does not recognize the percent sign (%) as a valid wildcard 
character. 
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• The directory component of a RSTS/E file specification cannot be a named 
directory list, such as [A.B.C]; it must be in UIC (user identification code) 
format, such as [1,2]. RSTS/E systems, however, express UICs in decimal 
radix, whereas VAX/VMS systems use octal numbers. On the RSTS/E 
system, the UIC is referred to as a PPN (project programmer number). 

To access a RSTS/E file whose directory component in PPN format 
contains decimal digits, use the quoted string form of the file specification. 
For example: 

$ TYPE RSTS::"SY:[9,18]TEST.DAT" 

• The file name component has a maximum length of six characters and the 
file type cannot exceed three characters. If you specify a longer file name, 
RSTS/E will truncate the name to six characters. 

• RSTS/E does not support version numbers. It will accept a file 
specification containing a version number without returning an error, 
but will ignore the version number. 


9.4.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the network, the 
following are not supported between VAX/VMS and a RSTS/E node: 

• PURGE 

• RENAME 

9.4.2.1 APPEND 

In using the APPEND command, you are limited to appending one local 
input file to an output file on the RSTS/E node. 


9.4.22 COPY 

The /EXTENSION and /PROTECTION qualifiers for the COPY command 
are not supported and will be ignored if specified. 

File creation date and time information is not preserved on a file copy 
operation to a RSTS/E node where wildcards are used in the output file 
specification. Instead, the current date and time is used as the file creation 
date and time. 

Because RSTS/E does not support version numbers in file specifications (it 
will ignore any version number supplied), an attempt to copy a file with 
an explicit version number will fail if a file with the same name and type 
already exists at the RSTS/E node. For example, if a file with the name 
RSTS::TEST.DAT already exists on the remote node, an attempt to update it 
by copying a new version of that file to the node will produce the following 
results: 

$ COPY TEST.DAT;2 RSTS::*.* 

'/.COPY-E-OPENOUT, error opening _RSTS: : TEST.DAT; 2 as output 
-RMS-E-FEX, file already exists, not superseded 
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9.4.2.3 DELETE 

If you use the DELETE command with a wildcard file specification to delete 
several files from a directory on a remote RSTS/E node, the operation may 
appear to complete successfully even though some of the files may remain in 
the directory. This behavior is caused by a file system incompatibility in the 
way VAX/VMS and RSTS/E perform wildcard file deletion operations. This 
problem will occur only if the remote directory has at least 30 files cataloged. 

To determine if all the files you specified have been deleted successfully, 
issue a DIRECTORY command to examine the remote directory. Then repeat 
the wildcard DELETE command if necessary to remove unwanted files. If 
the number of files you are attempting to delete is small, using the /LOG 
qualifier with the DELETE command may help you to determine if all the 
files have been deleted. 


9.4.2.4 DIRECTORY 

When you issue a DIRECTORY/FULL command to examine a RSTS/E 

file, the information displayed will differ from that which is displayed for a 

VAX/VMS file in the following respects: 

• The file owner is displayed as [0,0] if the owner of the file is identified by 
a UIC that contains decimal digits. 

• The file revision number shown will be either 0 or 1. A revision number 
of 0 indicates the file has not been revised; a revision number of 1 
indicates the file has been revised. 

• Under the attributes of an indexed file, information about the number of 
keys, the number of areas, and the prologue version number of the file is 
not displayed. This information is omitted because the RSTS/E FAL does 
not return file attribute information stored in the prologue portion of an 
indexed file. 

• Under the attributes of a relative file, the maximum record number is 
displayed as 0. 


9.4.2.5 DUMP/RECORDS and TYPE Commands 

Because RSTS/E does not support record mode access (nonblock I/O access) 
to indexed files, you cannot use the DCL commands DUMP/RECORDS and 
TYPE to examine indexed files located on the remote RSTS/E node. 


9.5 VAX/VMS to RSX Network Operation Using RMS-Based FAL 

This section pertains to a VAX/VMS node communicating with an RSX 
node running either DECnet-llM Version 4 or DECnet-llM-PLUS V2.0 
where the RSX File Access Listener (FAL) calls RMS-11 to perform local 
file operations. The discussion focuses on file operations initiated from the 
VAX/VMS node, to access remote files by means of the FAL at the RSX node. 


9.5.1 File System Constraints 

The restrictions described below are related to incompatible features in file 
system design between the two systems. 
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9.5.1.1 File Formats and Access Modes 

The following types of file and record attributes are not supported by 
VAX/VMS when communicating with an RSX node running the RMS-based 
FAL: 

• File organizations and record formats: 

Sequential Stream_CR (STMCR) 

Stream_LF (STMLF) 

Indexed All prologue 3 formats 

With 64-bit binary (BN8) key types 
With 64-bit integer (IN8) key types 

With descending key types (DSTG, DIN2, DBN2, DIN4, 
DBN4, DIN8, DBN8, DPAC) 

• Record attributes: 

(Record attributes are compatible) 

• File access modes: 

(Modes are compatible) 


9.5.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two VAX/VMS nodes, 
are not supported between a VAX/VMS node and an RMS-based RSX node: 

• VAX RMS service calls: 

SRELEASE 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP 


9.5.1.3 File Specifications 

The general format of a file specification for naming a file on a remote 

RSX-11M or RSX-11M-PLUS system is: 

node::device:[directory]name.type;version 

The following are major differences in syntax between file specifications used 

on RSX and VAX/VMS: 

• RSX systems do not support dollar sign ($) and underscore (_) characters 
in file name components. 

• The directory component in an RSX file specification cannot be a named 
directory list, such as [A.B.C]; it must be in UIC (user identification code) 
format, such as [15,1]. 

• The file name component has a maximum length of nine characters and 
the file type cannot exceed three characters. RSX systems will return an 
error if you specify a longer file name or file type. 

• RSX systems use octal version numbers in file specifications whereas 
VAX/VMS uses decimal version numbers. 
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9.5.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the network, the 
following is not supported between VAX/VMS and an RMS-based RSX node: 

• OPEN/WRITE 

9.5.2.1 COPY 

Because RSX-11M and RSX-11M-PLUS systems use octal version numbers in 
file specifications, an attempt to copy a file with a version number containing 
an 8 or 9 is rejected by the remote system. For example: 

$ COPY A.DAT;9 RSX::*.* 

'/.COPY-E-OPENOUT, error opening RSX: :A.DAT;9 as output 
-RMS-F-FNM, error in file name 

There are two ways to circumvent this problem. You can specify an 
appropriate octal version number in the output file specification, or you 
can specify a null or zero version number in the output file specification to 
force highest version number processing on the remote node. This latter 
technique is particularly useful when several files are copied with one DCL 
command. For example: 

$ COPY A.DAT;9 RSX::A.DAT;11 
$ COPY B.DAT;28 RSX::*.*; 

$ COPY B.DAT;28 RSX::*.*;0 
$ COPY *.DAT RSX::*.*;0 


9.6 VAX/VMS to RSX Network Operation Using FCS-Based FAL 

This section pertains to a VAX/VMS node communicating with an RSX node 
running DECnet-llM Version 4 or DECnet-llM-PLUS V2.0 where the RSX 
FAL calls the File Control Services (FCS-11) to perform file operations. The 
discussion focuses on file operations initiated from the VAX/VMS node to 
access remote files by means of the FAL at the RSX node. 


9.6.1 File System Constraints 

The restrictions described below are related to incompatible features in file 
system design between the two systems. 


9.6.1.1 File Formats and Access Modes 

The following types of files and access methods are not supported by 
VAX/VMS when communicating with an RSX node running the FCS-based 
FAL: 

• File organizations and record formats: 

Sequential Stream (STM) 

Stream_CR (STMCR) 

Stream_LF (STMLF) 

Variable with fixed control (VFC) where fixed header size is 
not 2 bytes 
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Relative All formats 

Indexed All formats 

• Record attributes: 

Print file carriage control (PRN) 

• File access modes: 

Random access by relative record number 
Random access by key value 
Random access by record file address 
Block I/O 

You can copy a sequential file in VFC format from a VAX/VMS node to an 
FCS-based RSX node provided that the file has a 2-byte fixed header with a 
carriage control attribute other than print file. To transfer a file having print 
file carriage control, such as a VAX/VMS batch log file, use the command 

$ CONVERT/FDL=VAR.FDL input-file output-file 

where the FDL control file VAR.FDL contains 

FILE 

ORGANIZATION sequential 

RECORD 

FORMAT variable 

CARRIAGE.CONTROL carriage.return 

The CONVERT command and associated FDL control file will transform the 
input file to variable-length format with implied carriage control and copy it 
to the remote node according to the output file specification. 


9.6.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two VAX/VMS nodes, 
are not supported between a VAX/VMS node and an FCS-based RSX node: 

• VAX RMS service calls: 

SDELETE SDISPLAY SEXTEND $FIND 

$FREE $READ SRELEASE $RENAME 

SREWIND $SPACE STRUNCATE SUPDATE 

SWRITE 

• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP field 
DEQ (default extension quantity) field 
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9.6.1.3 File Specifications 

The general format of a file specification for naming a file on a remote 

RSX-11M or RSX-11M-PLUS system is: 

node::device:[directory]name.type;version 

The following are major differences in syntax between file specifications used 

on RSX and VAX/VMS: 

• RSX systems do not support dollar sign ($) and underscore (_) characters 
in file name components. 

• The directory component in an RSX file specification cannot be a named 
directory list, such as [A.B.C]; it must be in UIC (user identification code) 
format, such as [15,1]. 

• The file name component has a maximum length of nine characters and 
the file type cannot exceed three characters. RSX systems will return an 
error if you specify a longer file name or file type. 

• RSX systems use octal version numbers in file specifications whereas 
VAX/VMS uses decimal version numbers. 


9.6.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the network, the 
following are not supported between VAX/VMS and an FCS-based RSX node: 

• ANALYZE/RMS-FILE 

• BACKUP 

• OPEN/WRITE 

• RENAME 

9.6.2.1 APPEND 

In using the APPEND command, you are limited to appending one local 
input file to an output file residing on the FCS-based RSX node. 


9.6.2.2 COPY 

The /EXTENSION and /PROTECTION qualifiers for the COPY command 
are not supported and will be ignored if specified. 

File creation date and time information is not preserved on a file copy 
operation to an RSX node where wildcards are used in the output file 
specification. Instead, the current date and time is used as the file creation 
date and time. 

Because RSX-11M and RSX-11M-PLUS systems use octal version numbers in 
file specifications, an attempt to copy a file with a version number containing 
an 8 or 9 is rejected by the remote system, as shown below: 

$ COPY A.DAT;9 RSX::*.* 

'/.COPY-E-OPENOUT, error opening RSX: :A.DAT;9 as output 
-RMS-F-FNM, error in file name 

There are two ways to circumvent this problem. You can either specify an 
appropriate octal version number in the output file specification, or you can 
specify a null or zero version number in the output file specification to force 
highest version number processing on the remote node. This latter technique 
is particularly useful when several files are copied with one DCL command. 
For example: 
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$ 

$ 

$ 

$ 


COPY A.DAT;9 
COPY B.DAT;28 
COPY B.DAT;28 
COPY *.DAT 


RSX::A.DAT;11 
RSX::*.*; 

RSX::*.*;0 
RSX::*.*;0 


9.7 VAX/VMS to RT-11 Network Operations 

This section pertains to a VAX/VMS node communicating with an RT-11 
node running DECnet-RT V2.1. The discussion focuses on file operations 
initiated from the VAX/VMS node, to access remote files by means of the 
FAL at the RT node. 


9.7.1 File System Constraints 

The file systems used by RT-11 and VAX/VMS are dissimilar in many 
respects. A fundamental difference between them involves the handling of 
file attribute information. When a file is created on a VAX/VMS system, 
attribute information about the file is stored in a header block on disk for use 
when the file is subsequently opened. The implication is that the structure of 
an established file cannot change. In contrast, RT-11 does not save attribute 
information such as file format with a file; it expects the user to provide this 
information when the file is opened. File attribute information, however, is 
not an input to VAX RMS when a file is opened. 

To provide transparent access to files on a remote RT-11 system, VAX RMS 
restricts the types of files that you can create and open on the remote node. 
When you access an RT-11 file in record mode, VAX RMS treats the file 
as having stream format. Block I/O access is permitted; the remote file is 
viewed as having fixed length 512 byte records where virtual block number is 
translated to relative record number. 


9.7.1.1 File Formats and Access Modes 

The following types of files and access methods are not supported by 
VAX/VMS when communicating with an RT node: 

• File organizations and record formats: 

Sequential Fixed length (FIX) without implied carriage control 

Stream_CR (STMCR) 

Stream_LF (STMLF) 

Variable length (VAR) without implied carriage control 
Variable with fixed control (VFC) 

Relative All formats 

Indexed All formats 

• Record attributes: 

FORTRAN carriage control (FTN) 

Print file carriage control (PRN) 

None specified (embedded carriage control) 

• Record access modes: 
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For record mode access, the only file type in common between the two 
systems is a sequential file in STM (stream) format. For convenience, 
however, when you are transferring a file to an RT-11 node, VAX RMS 
will automatically convert a VAX/VMS sequential file with fixed or variable 
format and implied carriage control to a sequential file with stream format 
and embedded carriage control. This automatic conversion is performed 
during a file create operation, and VAX RMS returns an alternate success code 
(RMS$_CVT_STM) to indicate that the file format has been modified. 

Note also that when a stream format file is retrieved from an RT-11 node, 
VAX RMS automatically changes the record attribute from embedded carriage 
control to implied carriage control. 

In general, text files created by the SOS Editor without line numbers being 
saved or by the EDT Editor can be copied to an RT-11 system. VAX/VMS 
batch log files and files created by the SOS Editor with line numbers intact, 
however, are stored in VFC format and cannot be copied to an RT-11 system 
in that form. To transfer this type of file, use the DCL command 

$ CONVERT/FDL=STM.FDL input-file output-file 

where the FDL control file STM.FDL contains 

FILE 

ORGANIZATION sequential 

RECORD 

FORMAT stream 

CARRIAGE.CONTROL none 

The CONVERT command and associated FDL control file will transform the 
input file to stream format with embedded carriage control and copy it to the 
remote node according to the output file specification. 


9.7.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two VAX/VMS nodes, 
are not supported between a VAX/VMS node and an RT-11 node: 

• VAX RMS service calls: 

SDELETE SDISPLAY SEXTEND $FIND 

SFREE SRELEASE SRENAME SREWIND 

SSPACE STRUNCATE $UPDATE 

• RMS extended attribute blocks: 

Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

ALQ (allocation quantity) field 

DEQ (default extend quantity) field 

CBT (contiguous-best-try) bit of FOP field 

CTG (contiguous) bit of FOP field 

SCF (submit command file) bit of FOP field 

SPL (spool file) bit of FOP field 

• Significant fields and bit options of the RAB: 

EOF (position to end of file) bit of ROP field 
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9.7.1.3 File Specifications 

The general format of a file specification for naming a file on a remote RT-11 

system is 

node::device:name.type 

The following are major differences in syntax between file specifications on 

RT-11 and VAX/VMS: 

• RT-11 does not support dollar sign ($) and underscore (_) characters in 
file name components. 

• RT-11 does not recognize the percent sign (%) as a valid wildcard 
character. 

• RT-11 does not have a directory component in its file specification. 

• The file name component has a maximum length of six characters and the 
file type cannot exceed three characters. If you specify a longer file name 
or file type, RT-11 will return an error. 

• RT-11 does not support version numbers. Specification of a version 
number, however, is permitted when you refer to an RT-11 file, because 
VAX RMS discards any version number before sending the file specified to 
the RT-11 FAL. 


9.7.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the network, the 
following are not supported between VAX/VMS and an RT-11 node: 


• 

ANALYZE/RMS—FILE 

• 

APPEND 

• 

BACKUP 

• 

OPEN/WRITE 

• 

PRINT/REMOTE 

• 

PURGE 

• 

RENAME 

• 

SUBMIT/REMOTE 


9.7.2.1 COPY 


The /ALLOCATION, /CONTIGUOUS, /EXTENSION, and /PROTECTION 
qualifiers for the COPY command are not supported and will be ignored if 
specified. 

Using COPY to merge several files into a single output file is not supported. 

RT-11 does not support version numbers in file specifications and supersedes 
files by default. Therefore, if you attempt to copy a file with the same name 
and type as one that already exists on the remote RT-11 node, the new file 
will supersede the old one. No warning message is displayed. 
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9.7.2.2 DELETE 

The DCL command DELETE requires that you specify an explicit or wildcard 
version number in the file specification. However, since RT-11 does not 
accept a file specification containing a version number, VAX RMS removes 
the version number before sending the file specification to the RT-11 system. 
To satisfy the requirements of both systems, specify a null version number in 
the file specification, as shown below. 

$ DELETE RT::TEST.DAT; 


9.8 VAX/VMS to TOPS-IO Network Operations 

This section pertains to a VAX/VMS node communicating with a TOPS-10 
node running DECnet-10 Version 4. The discussion focuses on file operations 
initiated from the VAX/VMS node, to access remote files by means of the 
FAL at the TOPS-IO node. 


9.8.1 File System Constraints 

The file systems used by TOPS-IO and VAX/VMS are dissimilar in many 
respects. A fundamental difference between them involves the handling of 
file attribute information. When a file is created on a VAX/VMS system, 
attribute information about the file is stored in a header block on disk for use 
when the file is subsequently opened. The implication is that the structure 
of an established file cannot change. In contrast, TOPS-IO does not save 
attribute information such as file format with a file; it expects the user to 
provide this information when the file is opened. File attribute information, 
however, is not an input to VAX RMS when a file is opened. 

To provide transparent access to files on a remote TOPS-IO system, VAX 
RMS restricts the types of files that you can create and open on the remote 
node. When you access a TOPS-IO file in record mode, VAX RMS treats the 
file as having stream format. 


9.8.1.1 File Formats and Access Modes 

Because of differences in file system design, the following types of files and 
access methods are not supported by VAX/VMS when communicating with a 
TOPS-IO node: 

• File organizations and record formats: 

Sequential Fixed length (FIX) without implied carriage control 

Stream _CR (STMCR) 

Stream_LF (STMLF) 

Variable length (VAR) without implied carriage control 
Variable with fixed control (VFC) 

Relative All formats 

Indexed All formats 

• Record attributes: 

FORTRAN carriage control (FTN) 

Print file carriage control (PRN) 

None specified (embedded carriage control) 
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• Record access modes: 

Random access by relative record number 
Random access by key value 
Random access by record file address 
Block I/O 

For record mode access, the only file type in common between the two 
systems is a sequential file in STM (stream) format. For convenience, 
however, when you are transferring a file to a TOPS-10 node, VAX RMS 
will automatically convert a VAX/VMS sequential file with fixed or variable 
format and implied carriage control to a sequential file with stream format 
and embedded carriage control. This automatic conversion is performed 
during a file create operation, and VAX RMS returns an alternate success code 
(RMS$_CVT_STM) to indicate that the file format has been modified. 

Note also that when a stream format file is retrieved from a TOPS-10 node, 
VAX RMS automatically changes the record attribute from embedded carriage 
control to implied carriage control. 

In general, text files created by the SOS Editor without line numbers being 
saved or by the EDT Editor can be copied to a TOPS-10 system. VAX/VMS 
batch log files and files created by the SOS Editor with line numbers intact, 
however, are stored in VFC format, and cannot be copied in that form to a 
TOPS-10 system. To transfer this type of file, use the DCL command 

$ CONVERT/FDL=STM.FDL input-file output-file 

where the FDL control file STM.FDL contains 

FILE 

ORGANIZATION sequential 

RECORD 

FORMAT stream 

CARRIAGE.CONTROL none 

The CONVERT command and associated FDL control file will transform the 
input file to stream format with embedded carriage control and copy it to the 
remote node according to the output file specification. 


9.8.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two VAX/VMS nodes, 
are not supported between a VAX/VMS node and a TOPS-10 node: 

• VAX RMS service calls: 

$DELETE SDISPLAY SEXTEND $FIND 

SFREE SREAD $RELEASE SRENAME 

$REWIND $SPACE STRUNCATE SUPDATE 

$WRITE 

• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

ALQ (allocation quantity) field 

DEQ (default extend quantity) field 

CBT (contiguous-best-try) bit of FOP field 
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9.8.1.3 File Specifications 

The general format of a file specification for naming a file on a remote 

TOPS-IO system is 

node::device[directory]name.type 

The following are the major differences in syntax between file specifications 

on TOPS-IO and on VAX/VMS: 

• The directory component of a TOPS-IO file specification is in PPN (project 
programmer number) format, such as [3655,7031], where the two numbers 
are in octal radix. The directory component can also be in extended PPN 
format containing up to five levels of subdirectories. An example of a 
directory component in extended PPN format is [10,20,A,B,C,D,E]. 

VAX/VMS cannot parse directory components in PPN format (with 
numbers larger than 377 octal) or handle extended PPN formats 
containing subdirectories. The DECnet-10 implementation, however, 
will accept directory components using period (.) instead of comma 
(,) delimiters, and will convert commas to periods when returning file 
specifications to VAX/VMS systems. Consequently, when you enter a file 
specification for a remote TOPS-IO system, use the VAX/VMS named 
directory list format for expressing TOPS-IO PPNs and extended PPNs. 
For example, use [3655.7031] or [10.20.A.B.C.D.E] to specify a directory 
component. 

• The file name component has a maximum length of six characters and the 
file type cannot exceed three characters. If you specify a longer file name, 
TOPS-IO will truncate the name to six characters. 

• TOPS-IO does not support version numbers. It will accept a file 
specification containing a version number without returning an error, 
but will ignore the version number. 


9.8.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the network, the 
following are not supported between VAX/VMS and a TOPS-IO node: 

• ANALYZE/RMS-FILE 

• APPEND 

• BACKUP 

• OPEN/WRITE 

• RENAME 

9.8.2.1 COPY 

The /ALLOCATION and /EXTENSION qualifiers to the COPY command are 
not supported and will be ignored if specified. 
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9.8.2.2 DIRECTORY 

When you issue a DIRECTORY/FULL command to examine a TOPS-IO file, 
the information displayed will differ in the following respects from that which 
is displayed for a VAX/VMS file: 

• The file owner is displayed as [0,0] to indicate that this information is not 
available. 

• The file revision number is not shown and file revision date and time 
information is not available from the TOPS-IO system. 

• The blocks used and blocks allocated values displayed, which indicate the 
size of the file, refer to 128-word pages (providing 640 bytes of storage), 
not 512-byte blocks. 


9.9 VAX/VMS to TOPS—20 Network Operations 

This section pertains to a VAX/VMS node communicating with a TOPS-20 
node running DECnet-20 V3.0. The discussion focuses on file operations 
initiated from the VAX/VMS node, to access remote files by means of the 
FAL at the TOPS-20 node. 


9.9.1 File System Constraints 

The file systems used by TOPS-20 and VAX/VMS are dissimilar in many 
respects. A fundamental difference between them involves the handling of 
file attribute information. When a file is created on a VAX/VMS system, 
attribute information about the file is stored in a header block on disk for use 
when the file is subsequently opened. The implication is that the structure 
of an established file cannot change. In contrast, TOPS-20 does not save 
attribute information such as file format with a file; it expects the user to 
provide this information when the file is opened. File attribute information, 
however, is not an input to VAX RMS when a file is opened. 

To provide transparent access to files on a remote TOPS-20 system, VAX 
RMS restricts the types of files that you can create and open on the remote 
node. When you access a TOPS-20 file in record mode, VAX RMS treats the 
file as having stream format. Although block I/O is supported by DECnet- 
20, it is not supported between VAX/VMS and TOPS-20 because the block 
sizes are different. 


9.9.1.1 File Formats and Access Modes 

Because of differences in file system design, the following types of files and 
access methods are not supported by VAX/VMS when communicating with a 
TOPS-20 node: 

• File organizations and record formats: 

Sequential Fixed length (FIX) without implied carriage control 

Stream_CR (STMCR) 

Stream_LF (STMLF) 

Variable length (VAR) without implied carriage control 
Variable with fixed control (VFC) 
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Relative All formats 

Indexed All formats 

• Record attributes: 

FORTRAN carriage control (FTN) 

Print file carriage control (PRN) 

None specified (embedded carriage control) 

• Record access modes: 

Random access by relative record number 
Random access by key value 
Random access by record file address 
Block I/O 

For record mode access, the only file type in common between the two 
systems is a sequential file in STM (stream) format. For convenience, 
however, when you are transferring a file to a TOPS-20 node, VAX RMS 
will automatically convert a VAX/VMS sequential file with fixed or variable 
format and implied carriage control to a sequential file with stream format 
and embedded carriage control. This automatic conversion is performed 
during a file create operation, and VAX RMS returns an alternate success code 
(RMS$_CVT_STM) to indicate that the file format has been modified. 

Note also that when a stream format file is retrieved from a TOPS-20 node, 
VAX RMS automatically changes the record attribute from embedded carriage 
control to implied carriage control. 

In general, text files created by the SOS Editor without line numbers being 
saved or by the EDT Editor can be copied to a TOPS-20 system. VAX/VMS 
batch log files and files created by the SOS Editor with line numbers intact, 
however, are stored in VFC format, and cannot be copied in that form to a 
TOPS-20 system. To transfer this type of file, use the DCL command 

$ CONVERT/FDL=STM.FDL input-file output-file 

where the FDL control file STM.FDL contains 

FILE 

ORGANIZATION sequential 

RECORD 

FORMAT stream 

CARRIAGE.CONTROL none 

The CONVERT command and associated FDL control file will transform the 
input file to stream format with embedded carriage control and copy it to the 
remote node according to the output file specification. 
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9.9.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two VAX/VMS nodes, 
are not supported between a VAX/VMS node and a TOPS-20 node: 

• VAX RMS service calls: 

SDELETE SDISPLAY SEXTEND $FIND 

SFREE $READ $RELEASE SRENAME 

SREWIND SSPACE STRUNCATE SUPDATE 

$WRITE 

• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

ALQ (allocation quantity) field 
DEQ (default extend quantity) field 
CBT (contiguous-best-try) bit of FOP field 
CTG (contiguous) bit of FOP field 

• Significant fields and bit options of the RAB: 

EOF (position to end of file) bit of ROP field 


9.9.1.3 File Specifications 

The general format of a file specification for naming a file on a remote 

TOPS-20 system is 

node::device<directory>name.type.version 

The following are the major differences in syntax between file specifications 

on TOPS-20 and on VAX/VMS: 

• TOPS-20 uses angle brackets ( <> ) to delimit the directory string 
instead of square brackets ([]). To facilitate communication with 
TOPS-20, VAX RMS recognizes angle brackets as valid directory 
component delimiters. 

• TOPS-20 uses the period (.) to delimit the version number instead of the 
semicolon (;). However, you can specify either a period or a semicolon 
because VAX RMS converts a semicolon version number delimiter to a 
period before sending the file specification to the TOPS-20 FAL. 


9.9.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the network, the 
following are not supported between VAX/VMS and a TOPS-20 node: 

• ANALYZE/RMS-FILE 

• APPEND 

• BACKUP 

• OPEN/WRITE 

• RENAME 


9-22 








File Operations in a Heterogeneous Network Environment 


9.9.2.1 COPY 

The /ALLOCATION, /CONTIGUOUS, /EXTENSION, and /PROTECTION 
qualifiers to the COPY command are not supported and will be ignored if 
specified. 

File creation date and time is not preserved during a file copy operation. 
Using COPY to merge several files into a single output file is not supported. 


9.9.2.2 DIRECTORY 

When you issue a DIRECTORY/FULL command to examine a TOPS-20 file, 

the information displayed will differ in the following respects from that which 

is displayed for a VAX/VMS file: 

• The file owner is displayed as [0,0] to indicate that this information is not 
available. 

• The file revision number is not shown. 

• The blocks used and blocks allocated values displayed, which indicate the 
size of the file, refer to 128-word pages (providing 640 bytes of storage), 
not 512-byte blocks. 

• TOPS-20 does not have the equivalent of world protection, so this 
attribute is displayed as a null string. 


9.10 VAX/VMS to VAX/VMS Network Operations (Version 4 to 

Version 3) 

This section pertains to file operations initiated on a VAX/VMS Version 4 
node running DECnet-VAX Version 4 where the remote system is a V3.n 
node running DECnet-VAX V3.1. 


9.10.1 File System Constraints 

The restrictions described below are related to new features in DECnet-VAX 
Version 4 for remote file access that were not supported in DECnet-VAX 
V3.1. 


9.10.1.1 File Formats and Access Modes 

The following types of files and access methods are not supported by 
VAX/VMS when communicating with a VAX/VMS V3.n node: 

• File organizations and record formats: 

Sequential Stream_CR (STMCR) 

Stream_LF (STMLF) 

Indexed With 64-bit binary (BN8) key types 

With 64-bit integer (IN8) key types 

With descending key types (DSTG, DIN2, DBN2, DIN4, 
DBN4, DIN8, DBN8, DPAC) 


• Record attributes: 

(Record attributes are compatible) 
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• File access modes: 

(Modes are compatible) 


9.10.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two VAX/VMS Version 
4 nodes, are not supported between a VAX/VMS Version 4 node and a 
VAX/VMS V3.n node: 

• VAX RMS service calls: 

SRENAME 

• RMS extended attribute blocks: 

(No differences) 

• Significant fields and bit options of the FAB: 

(No differences) 


9.10.1.3 File Specifications 

The general format of a file specification for naming a file on a remote 

VAX/VMS V3.n system is 

node::device:[directory]name.type;version 

The following are major differences in syntax between file specifications used 

on VAX/VMS V3.n and on VAX/VMS Version 4: 

• VAX/VMS V3.n systems do not support dollar sign ($) and underscore 
(_) characters in file name components. 

• The file name component has a maximum length of nine characters and 
the file type cannot exceed three characters. VAX/VMS V3.n systems will 
return an error if you specify a longer file name or file type. 


9.10.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the network, the 
following is not supported between a VAX/VMS Version 4 node and a 
VAX/VMS V3.n node: 

• RENAME 


9.11 VAX/VMS to VAX/VMS Network Operations (Version 4.4 to 
Previous Version) 

This section pertains to file operations initiated on a VAX/VMS Version 
4.4 node running DECnet-VAX Version 4.4 where the remote system is a 
VAX/VMS node running a previous release of DECnet-VAX. 


9.11.1 File System Constraints 

The restriction described below indicates a new feature not previously 
supported by DECnet-VAX. 
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9.11.1.1 File Formats and Access Modes 

The following type of file is not supported by VAX/VMS when 
communicating with a VAX/VMS node running a previous DECnet-VAX 
release: 

• File organization and record format: 

Indexed With descending key types (DSTG, DIN2, DBN2, DIN4, 

DBN4, DIN8, DBN8, DPAC) 
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A Area Routing Configuration 


Phase IV DECnet supports area routing, which permits the configuration 
of networks in which the nodes are grouped into areas. This appendix 
presents recommendations and guidelines for configuring networks that use 
area routing. It illustrates the guidelines with an example of the design of a 
multiple-area network, and indicates the NCP commands required to build 
the configuration database for this network. The appendix also recommends a 
procedure for converting an existing network to a multiple-area network. The 
next section of the appendix describes problems that can occur when you are 
configuring an area-based network, and includes suggestions for solving these 
problems. The final section discusses area routing on the Ethernet. 

Area routing concepts are described in detail in Section 2.4. Area routing 
techniques enable configuration of a network consisting of a number of areas; 
each area is a group of nodes that forms a subnetwork. DECnet supports 
routing of packets within areas and a second level of routing between areas. 
The router that performs routing within an area is called a level 1 router; the 
router that performs routing to and from other areas as well as within its own 
area is called a level 2 router (or area router). 

Each level 1 router keeps information on the state of all nodes in its area, but 
not on the state of nodes outside its area. It routes all packets addressed to 
nodes outside its area to the nearest level 2 router. Each level 2 router keeps 
information on the least-cost path to areas throughout the network, as well as 
the state of the nodes in its own area. When a level 1 router receives a packet 
destined for a node in another area, it uses level 1 routing to send the packet 
to the nearest level 2 router in its own area. The level 2 router forwards the 
packet along the least-cost path to the nearest level 2 router outside its area. 
The packet is transmitted along a level 2 path to the level 2 router in the 
destination area; this level 2 router sends the packet by level 1 routers to the 
destination node. 

Thus, a basic reason for dividing a network into multiple areas would be 
to reduce the amount of routing traffic that would occur in a single-area 
network. 


A.1 Area Routing Configuration Guidelines 

Configuration of a network that consists of multiple areas is more complex 
than configuration of a network that, by default, consists of a single area. 

The design of a multiple-area network introduces a second, higher level of 
routing that links the areas. Designing a network for area routing involves 
awareness of certain network topological restrictions unique to area routing 
configurations. The area routing configuration guidelines presented below are 
based on these restrictions. The guidelines are intended to prevent problems 
such as loss of routing path, isolation of nodes, or incorrect routing of packets. 
These potential problems are discussed in Section A.5. 
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When you configure a multiple-area network, you should follow these 
guidelines: 

• Each node must belong in only one area. This restriction applies to all 
nodes in the network. Phase III nodes as well as Phase IV nodes. Phase 
III nodes must be logically associated with a single area even though they 
are not assigned an area number by network management, and must not 
have circuits outside the area. 

• Only a level 2 router can establish a circuit with a node in another area, 
thus enabling communication between the areas. A level 1 router cannot 
have any circuits outside its own area. 

• Within a network, the level 2 routers must form a subnetwork; that is, 
they must be connected in such a way that they create a network of their 
own. There must be a level 2 routing path between any pair of level 2 
routers across the network. Level 1 routers do not forward level 2 routing 
information. 

• Treat each area as though it were a separate network. Each area must 
be physically intact and capable of running on its own. Within the area, 
there must be a level 2 path between any pair of level 2 routers. 

• Provide enough redundancy within each area and between areas to avoid 
having a single point of failure in the network. For redundancy within 
an area, you could include more than one level 2 router and provide for 
alternate paths between nodes. This redundancy will prevent loss of the 
routing path within the area or isolation of any one node. For redundancy 
between areas, you could provide for alternate paths between areas so that 
loss of a line does not disconnect any area from the rest of the network. 
Complete redundancy may not be feasible, however, for certain networks, 
such as small networks. 

• Place all Phase III nodes on the periphery in each area. Do not place a 
Phase III node in a path between two Phase IV nodes. A Phase III node 
cannot communicate directly with nodes in other areas or with nodes in 
the same area that have addresses greater than 255. 

• Do not link a Phase III node in one area with a node in another area. 
Such a connection could lead to area leakage, a problem described in 
Section A.5.2.2. 

The recommended approach to designing a multiple-area network 
configuration is to begin by designing the level 2 routers, area by area, into 
a level 2 subnetwork. Then, in each area, add the level 1 routers. Finally, 
add the end nodes required to complete each area. This design approach is 
illustrated below. 


A.2 Designing a Multiple-Area Network 

This section demonstrates the use of the configuration guidelines in designing 
a multiple-area network. The goal of the design process is to build a robust, 
redundant network that will not be subject to a single point of failure. 

Figure A-l shows the level 2 routers as a subnetwork of a multiple-area 
network. For purposes of illustration, DMR lines are used to connect level 2 
routers within each area and DMC lines to connect level 2 routers in different 
areas. In each area, the level 2 routers are configured in pairs for redundancy 
and connected by enough DMR lines so that the loss of one DMR line does 
not prevent the flow of level 2 routing traffic through the area. Redundancy 
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between different areas is achieved by the way in which the DMC lines 
connect level 2 routers in the different areas. If one of the DMC lines fails, 
level 2 routing traffic can still reach each area by an alternate path. In area 9, 
the redundant level 2 routers that form part of a VAXcluster are connected by 
a Cl line. 

Figure A-1 Level 2 Router Subnetwork of a Multiple-Area 
Network 


AREA 7 AREA 8 



ZK-1995-84 


Figure A-2 shows the next stage of the design process: adding the level 1 
routers and the end nodes to each area. The figure does not include all the 
nodes that might be required to make the network complete. It illustrates 
only a few typical uses of level 1 routers and end nodes, indicating the way 
in which you could add such nodes to the level 2 subnetwork to complete the 
network design. 
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Ethernet 

ZK-1996-84 


In Figure A-2, in area 7, an end node and a level 1 router are attached 
directly to the first Ethernet. MicroVMS end nodes are connected to the 
level 1 router by means of DDCMP asynchronous lines. Another end node 
is connected to a level 2 router attached to the second Ethernet (lower left) 
in area 7. Because this end node is not on a routing path between level 2 
routers, it could possibly be a Phase III end node. In area 9, two level 1 
routers are added to the redundant level 2 routers in a VAXcluster. 
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The network design shown in Figure A-2 ensures a robust network not 
vulnerable to a line or node failure that could isolate or bring down an area. 
A fully redundant multiple-area network, such as that in Figure A-2, may not 
be practical for smaller networks, however. Redundancy is a desirable design 
goal, not a requirement, in a multiple-area network. 


When you complete the design of a multiple-area network, begin network 
configuration by configuring each area separately, as though it were a network 
by itself. An example of the NCP commands required to configure area 7 of 
the network in Figure A-2 is given in the following section. Once you have 
configured all areas in the network and they are running and stable, connect 
the areas. 
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Sample Multiple-Area Network Configuration 

The example below illustrates how you can use NCP commands to configure 
a multiple-area network. It lists the NCP commands required to build the 
permanent database for one area of the large multiple-area network shown in 
Figure A-2, and indicates how to complete the network configuration. 

This example builds a database for a network configuration of twelve nodes 
in area 7, as depicted in Figure A-3. Area 7 is connected to areas 8 and 9. 
The database being built is for node A. Similar commands would be issued 
to create the database for each of the other nodes in area 7, and each of the 
nodes in areas 8 and 9. 
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Figure A-3 Area 7 of a Multiple-Area Network 


AREA 7 


(7.10) 



Ethernet 


(n.n) Address 


ZK-1997-84 
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Define executor-specific parameters for local node A. 

Note that the TYPE parameter for the executor node 
defaults to either NONROUTING IV or ROUTING IV, depending 
on whether an end node or full function key has been 
installed. In this example, node A needs to be a level 2 
router, so the TYPE parameter is set accordingly. 

DEFINE EXECUTOR ADDRESS 7.1 - 

BUFFER SIZE 576 - 
STATE ON - 
TYPE AREA - 
DEFAULT PROXY BOTH 

Define common node parameters for the local node. Be 
sure to add the NETNONPRIV user to your system 
authorization file by using the Authorize Utility. 

DEFINE EXECUTOR NAME A - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV - 

Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 


each 

remote 

node when it 

as a 

result 

of a proxy 1< 

DEFINE 

NODE 

B 

ADDRESS 

7.2 

DEFINE 

NODE 

C 

ADDRESS 

7.3 

DEFINE 

NODE 

D 

ADDRESS 

7.4 

DEFINE 

NODE 

E 

ADDRESS 

7.5 

DEFINE 

NODE 

F 

ADDRESS 

7.6 

DEFINE 

NODE 

G 

ADDRESS 

7.7 

DEFINE 

NODE 

H 

ADDRESS 

7.8 

DEFINE 

NODE 

I 

ADDRESS 

7.9 

DEFINE 

NODE 

J 

ADDRESS 

7.10 

DEFINE 

NODE 

K 

ADDRESS 

7.11 

DEFINE 

NODE 

L 

ADDRESS 

7.12 

If node L 

is a Phase III 


to specify routing initialization passwords to 
initialize this node. Using the number of the area in 
which the Phase III node resides as part of the password 
will avoid accidental connection to another area. 

Define a receive password for node L as follows: 

DEFINE NODE L RECEIVE PASSWORD AREA7 
In this case, on node L, the transmit password would be 
set to match: 

DEFINE NODE A TRANSMIT PASSWORD AREA7 ! (on node L) 

Note that although nodes M and N reside in different 
areas, no special action is needed in defining them. 
Continue defining nodes in other areas in this fashion. 

DEFINE NODE M ADDRESS 8.3 
DEFINE NODE N ADDRESS 9.42 

Set up the line and circuit for the Ethernet connected 
to node A. 

DEFINE LINE UNA-0 STATE ON 
DEFINE CIRCUIT UNA-0 STATE ON 
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Set up the line and circuit for each DMR connected to 
node A. Note that a DMR line is treated like a DMC line. 

DEFINE LINE DMC-1 STATE ON 
DEFINE CIRCUIT DMC-1 STATE ON 
DEFINE LINE DMC-2 STATE ON 
DEFINE CIRCUIT DMC-2 STATE ON 

Set up the line and circuit for the DMC connected to 
node A. Because the DMC leads to another area, you 
may want to leave this circuit and line in the OFF state 
while you are initially configuring your area, turning 
them on only after the connections within your area 
have been tested. 

DEFINE LINE DMC-0 STATE ON 
DEFINE CIRCUIT DMC-0 STATE ON 

The object database does not need to be defined, since it 
defaults to the standard list of objects known to VAX/VMS. 

Define the transmitter-related logging parameters. 

DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 

DEFINE LOGGING MONITOR STATE ON 


A.4 Converting an Existing Network to a Multiple-Area Network 

Converting an existing single-area network to a multiple-area network 
requires careful planning. Because the network addresses of existing nodes 
will change, there may be a period during which some nodes are unreachable 
while the conversion is under way. The following steps illustrate an approach 
that can keep this disruption to a minimum. 

1 Plan ahead. Completely define what the entire network topology will be 
with multiple areas. Make sure the topology follows the guidelines listed 
in Section A.l. Decide which nodes should be level 2 routers, level 1 
routers, and end nodes. 

2 If the new design requires that some nodes be moved, make the required 
changes before you begin converting node addresses. (For example, the 
redesign may involve reconnecting a Phase III node so that it is not in a 
path between two Phase IV nodes.) 

3 Create new node databases. Without modifying the existing permanent 
node databases, create a new copy of the node database on each node in 
the network. This is most easily done as follows for DECnet-VAX nodes: 

a Use the logical name NETNODE —REMOTE to point to the working 
copy of the remote node file you are creating and use the logical name 
NETNODE—LOCAL to point to the working copy of the local node file 
you are creating. These logical names will be translated when NCP is 
reading the permanent database, and the default versions 
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of NETNODE_REMOTE.DAT and NETNODE_LOCAL.DAT in 
SYS$SYSTEM: will remain untouched. Set up this environment as 
follows: 

$ COPY SYS$C0MM0N:[SYSEXE]NETNODE.REMOTE.DAT - 
_ SYS$MANAGER:NEWNETN0DE_REM0TE.DAT 
$ COPY SYS$SPECIFIC:[SYSEXE]NETNODE.LOCAL.DAT - 
_ SYS$MANAGER:NEWNETNODE.LOCAL.DAT 

$ ASSIGN/USER.MODE SYS$MANAGER:NEWNETNODE.REMOTE.DAT NETNODE.REMOTE 
$ ASSIGN/USER.MODE SYS$MANAGER:NEWNETNODE.LOCAL.DAT NETNODE.LOCAL 
$ RUN SYS$SYSTEM:NCP 
NCP> 

When the NCP prompt appears, enter the changes, which will be made 
to the new database. 

b In your remote node file, change the addresses of existing nodes in 
the network to reflect the new topology with areas. If you are adding 
new nodes to the network (for example, if two existing separate 
networks are to be merged), include their new addresses in your file 
now. Make sure these changes are only made to the working copies 
of the files, and not to SYS$SYSTEM:NETNODE_JREMOTE.DAT 
or SYS$SYSTEM:NETNODE_LOCAL.DAT. For now, the database 
changes need to be made on only one node in the network. Also, to 
modify the executor, issue the commands 

ncp>purge executor address 

NCP>DEFINE NODE local._node_.name ADDRESS ... 

NCP>DEFINE EXECUTOR ADDRESS ... 

c When SYS$MANAGER:NEWNETNODE_REMOTE.DAT and 

SYS$MANAGER:NEWNETNODE_LOCAL.DAT correctly reflect the 
new topology, copy SYS$MANAGER:NEWNETNODE_REMOTE.DAT 
to the SYS$MANAGER directory on each node in the network. (Note 
that this should be done only for nodes which are running the same 
version of VAX/VMS. If you have different versions in the network, 
the conversion procedure should be followed independently for each 
version.) 

On each VAX/VMS node on the network, define the executor 
parameters in NEWNETNODE_LOCAL.DAT as follows: 

$ COPY SYS$SPECIFIC:[SYSEXE]NETNODE.LOCAL.DAT - 
_ SYS$MANAGER:NEWNETNODE.LOCAL.DAT 

$ ASSIGN/USER.MODE SYS$MANAGER:NEWNETNODE.REMOTE.DAT NETNODE.REMOTE 
$ ASSIGN/USER.MODE SYS$MANAGER:NEWNETNODE.LOCAL.DAT NETNODE.LOCAL 
$ RUN SYS$SYSTEM:NCP 
NCP>DEFINE EXECUTOR ADDRESS ... 

Using the NCP command DEFINE EXECUTOR, set up each local 
node with the correct area and node address, correct executor type 
(nonrouting IV, routing IV, or area), and other executor parameters. 

Similarly, convert the node database on each non-VAX node in your 
network using the tools available for each implementation. 

4 Shut down the network and bring it up again with the new database. 

This is the only part of the conversion process which benefits from 
real-time cooperation among the nodes in your network. If this level 
of coordination is not feasible, then avoid using area number 1 for any 
area in the revised network, since node address duplications might occur 
during the transition period. 
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At approximately the same time, have each node in the network shut 
down DECnet. It is not necessary to shut down the operating system. Use 
the command 

NCP>SET EXECUTOR STATE SHUT 

When all nodes have shut down DECnet (or after an agreed-upon interval 
during which all nodes should have shut down DECnet), rename the new 
copy of the database and restart the network at each node: 

$ RENAME SYS$MANAGER:NEWNETNODE_REMOTE.DAT - 
_ SYSSCOMMON:[SYSEXE]NETNODE_REMOTE.DAT 
$ RENAME SYS$MANAGER:NEWNETNODE_LOCAL.DAT - 
_ SYS$SPECIFIC:[SYSEXE]NETN0DE_L0CAL.DAT 
$ <DSYS$MANAGER: STARTNET 

Note that if your node is on an Ethernet to which applications other 
than DECnet (such as LAT) are connected, these applications should also 
be shut down along with DECnet, and then restarted after DECnet is 
restarted. This step is necessary because DECnet will be changing the 
Ethernet physical address of your node to reflect the new executor node 
address (see Section 3.3.4.1). 

5 Use NCP to monitor the reconfigured network. 

Depending on the size of the network and the care with which the conversion 
was done, there may be a period of debugging the network to ensure that 
all desired connections have been made. You can simplify debugging the 
conversion if you can run each area separately for a while before connecting 
them. You can do this by turning the circuits between level 2 routers in 
different areas to the OFF state in the new copy of the database. Once you 
are confident that an area is operating to your satisfaction, you can turn on 
the circuits joining this area to its neighboring areas. Of course, while the 
interarea circuits are off, nodes in those areas will not be accessible to nodes 
in other areas. This circumstance may be viewed as a tradeoff to reduce the 
number of variables during the conversion. 


A.5 Problems in Configuring a Multiple-Area Network 

The use of area routing techniques in configuring a network can lead to 
certain problems that may not be readily identifiable. This section describes 
some problems related to violation of the area routing configuration guidelines 
presented in Section A.l, and explains how to solve these problems. 


A.5.1 Partitioned Area Problem 

Improper configuration of the network topology for a multiple-area network 
can result in a failure condition that can cause traffic to be incorrectly routed 
and/or lost. The problem is called area partitioning; it occurs when an area 
is broken into separate parts as the result of the failure of one or more lines 
or nodes. As a consequence of partitioning, a node may be isolated within an 
area. 
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Figure A-4 illustrates an improper network design, in which an area is 
vulnerable to partitioning if a single line should fail. All circuit costs in 
Figure A-4 are equal to 1. Node C in area 3 attempts to communicate with 
node D in area 4. If either link w or x fails, there is no problem because the 
remaining path into area 4 provides a route to node D. If link y or z fails, the 
level 2 router in area 3 will find the path to the level 2 router in area 4 on the 
basis of the least-cost algorithm; the path would be from node C to node B to 
node A. Because link y or z is down, however, it is not possible to get to the 
destination node D. 


Figure A-4 Partitioned Area Problem 



AREA 2 


AREA 3 


ZK-2000-84 


When the initial connection is attempted, the network turns on the "return 
to sender" bit and sends a message to the sender indicating the node is 
unreachable. If the two nodes have already established a link before the 
connection breaks, the sender will time out, because the network will not 
route back traffic once it arrives at the destination area. Thus a node in an 
area is isolated because of a line failure. 
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Figure A-4 illustrates another problem. If link z is down and node D wants 
to create a link to node B, the path that node D chooses is to route through 
area 2 and then to node B. On the return trip, however, node B will attempt 
to send the reply to node A, but link z is down, and therefore the reply will 
not be delivered to node D. 

The solution to the problem of area partitioning is to treat each area as a 
separate network when configuring a multiple-area network. Designing an 
area as a straight-line configuration, as in area 4 in the figure, should be 
avoided. Also, all the level 2 routers in a given area should be linked in a 
level 2 routing path; a level 1 router should not be included on the same 
path. In the configuration in Figure A-4, installing a link between nodes A 
and D would provide for an alternate path between nodes in the same area. 


A.5.2 Problems in Mixed Phase Ill/Phase IV Networks 

In a Phase IV multiple-area network. Phase III nodes can be included 
provided certain rules are followed: Phase III nodes in a multiple-area 
network must not be in the routing path between Phase IV nodes and must 
not be linked to nodes outside their own area. These limitations are based on 
the following restrictions under which Phase III nodes operate in a Phase IV 
network: 

• DECnet-VAX Phase III nodes cannot assume a node address greater than 
255, and cannot directly address a node with a node address greater than 
255. They also cannot route through traffic for nodes with addresses 
greater than 255. (Note that this limit may vary for other DECnet Phase 
III nodes, up to a maximum possible address of 1023.) 

• Phase III nodes cannot recognize area numbers in node addresses. A 
Phase III node cannot assume an area address, directly address a node 
outside its own area, or route through traffic for nodes in other areas. 

• Phase III nodes cannot be connected directly to an Ethernet. 

• Phase III nodes must use routing initialization passwords when they are 
initialized in a Phase IV network (see Section A.5.2.2). 

The node address is represented in different ways in Phases III and IV. In 
Phase III a node address is represented by a single decimal number, such as 
99. For DECnet-VAX, the maximum node address of a Phase III node is 255. 
In Phase IV a node address is represented by a number in the format 

area-number.node-number 

where the maximum area-number is 63 and the maximum node-number is 
1023. If Phase IV node number 99 is in area 33, its node address is 33.99. (If 
a Phase IV network is not configured into areas, node number 99, by default, 
is in area number 1 and is represented in the database by the node address 
1.99.) 

Whenever a Phase III node is brought up in a Phase IV multiple-area 
network, the physical link is initialized with the Phase III protocol and all 
references to the area number are dropped. Routing in the network is affected 
in different ways, depending on the direction in which traffic is flowing: 

• If traffic is going from a Phase IV node to the Phase III node, the area 
number is dropped from the node address. For example, when node 
address 19.201 is passed to a Phase III node, the node address becomes 
201 . 
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• If traffic is going from a Phase III node to a Phase IV node, the area 
number of the Phase IV node is added to the node address. For example, 
if node address 143 is sent to Phase IV node 75.5, the node address 143 
becomes 75.143. 

• If a packet is routed through a Phase III node, the area number is dropped 
from both the source and destination node addresses in the routing header 
of the packet. 


A.5.2.1 Problem of a Phase III Node in a Phase IV Path 

An example of the problem caused by placing a Phase III node in the 
routing path between two Phase IV nodes in the same area is illustrated 
in Figure A-5. 

Figure A-5 Problem of Phase III Node In Phase IV Path 
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No problem occurs if the entire logical link path is within a single area and 
if none of the nodes have node numbers greater than 255. For example, for 
node 4.88 to send a packet to node 4.45, the packet first goes to node 22 (the 
Phase III node has no area number even though it is in area 4). Node 22 
discards the area number from the destination node address 4.45, making it 
address 45, and from the source node address 4.88, making it address 88. The 
packet is then forwarded to node 4.45, which adds its own area number to 
the destination address, making it 4.45, and to the source address 88, making 
it 4.88. 

During the return trip from node 4.45 to 4.88, the packet (with source address 
4.45 and destination address 4.88) goes through node 22 and loses the 
area numbers from the source and destination node addresses in its routing 
header. When the packet arrives at its destination, node 4.88 adds its own 
area number to the node addresses in the routing header, making the source 
address 4.45 and the destination address 4.88. 

A problem occurs, however, during communication between nodes in 
different areas, when the routing path in one area includes a Phase III 
node between two Phase IV nodes. In the example in Figure A-5, if node 
2.72 wants to send a packet to node 4.45, the packet goes from node 2.72 to 
node 4.88 and then to node 22, which drops the area number from both the 
source and destination addresses in the routing header, making the source 
address 72 and the destination address 45. Node 22 then sends the packet to 
the destination, node 4.45, which adds its area number to the source address, 
making it 4.72, and to the destination address, making it 4.45. The problem 
arises during the return trip. Node 4.45 attempts to respond by sending a 
packet addressed to destination node 4.72 instead of 2.72. If a node with 
address 4.72 does exist, the return packet is incorrectly delivered to that node. 
Node 2.72 does not receive a reply and eventually times out. 


A.5.2.2 Area Leakage Problem 

When a Phase III node is included in a Phase IV network that has been 
divided into multiple areas, the Phase III node should not be connected to 
a node outside its own area (as in Figure A-6). A Phase III node drops the 
area number from a node address. Permitting a Phase III node to have a 
link to another area causes a problem known as "area leakage." When the 
Phase III node builds its routing database, it includes the node addresses of 
adjacent nodes minus their area numbers. This incorrect information is then 
transmitted (or "leaked") across the area boundaries. This problem occurs 
whether the Phase IV nodes are level 1 or level 2 routers. 

In Figure A-6, node R is a Phase III node with links to nodes in areas 12 
and 14. Node R will build a routing database that contains the addresses 
of nodes P, Q, and S, but the area numbers will be missing from the node 
addresses. Node R will send routing updates to all adjacent nodes, without 
recognizing area boundaries. Thus node R will send routing information 
about nodes P and Q (minus the correct area designation) to node S. Node 
S will assume that nodes P and Q are nodes in its own area that have the 
addresses 12.6 and 12.7, respectively, instead of the correct addresses 14.6 
and 14.7. Similarly, node R will send the address of node S (minus its area 
number) to nodes P and Q; nodes P and Q will assume that node S is in their 
own area and has the address 14.5 rather than the correct address 12.5. 

Routing initialization passwords are required when a Phase III node is 
initialized in a Phase IV network (see Section 2.10.1 for a description of 
the passwords). If no password is specified during routing initialization, a 
specific event class message will be generated, indicating that a password is 
required or is mismatched. If the network manager has turned on the event 
logger, he or she can read these messages to learn which Phase III nodes 
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Figure A-6 Area Leakage Problem 
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have not been initialized. The network manager can use this information to 
prevent Phase III nodes from linking to nodes outside their own areas, or to 
identify which Phase III nodes need to have the transmit password set. It is 
recommended that the number of the area in which the node resides be used 
in the password, to prevent accidental connection to a node in a wrong area. 

Note that this technique will not locate Phase III nodes improperly linked 
to nodes in other areas if the Phase III nodes were configured using 
routing initialization passwords before conversion to area routing, unless 
the passwords were changed as recommended during the conversion. 


A.6 Area Routing on an Ethernet 

Phase IV DECnet supports configuration of multiple areas on an Ethernet. 
This configuration results in higher message overhead because a packet must 
be routed through two level 2 routers rather than being delivered directly to 
the destination node. Figure A-7 shows two areas sharing the same Ethernet 
cable. When a node in area 5 wishes to communicate with a node in area 7, 
the packet is routed through the two level 2 routers. For example, if node 5.3 
sends a packet to node 7.8, the packet follows this path: 

• Node 5.3 to node 5.2 (source to its nearest level 2 router) 

• Node 5.2 to node 7.4 (level 2 router to level 2 router) 

• Node 7.4 to node 7.8 (level 2 router to destination) 
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Figure A—7 Area Routing on an Ethernet 
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access control: Validating connect, login, or file-access requests to determine whether 
they can be accepted. User name and password provide the most common means of 
access control. 

account name: A string that identifies a particular account used to accumulate data 
on a job's resource use. This name is the user's accounting charge number, not the 
user's UIC. 

active component: A component whose operational state is other than OFF. 

The word ACTIVE can be used with the SHOW or LIST commands to display 
information about active lines, circuits, nodes, and logging. 

adjacent node: A node removed from the local node by a single physical line. 

alias node identifier: An optional node name or address, common to some or all 
nodes in a VAXcluster, that permits the VAXcluster to be treated as a single node. 

area: A group of nodes in a network that can run independently as a subnetwork. 

area router: A level 2 router. 

area routing: A technique for grouping the nodes in a network into areas for routing 
purposes. Routing in a multiple-area network is hierarchical, with one level of 
routing within an area (level 1 routing) and a second, higher level of routing 
between areas (level 2 routing). 

asynchronous transmission: A mode of data transmission in which the time 

intervals between transmitted characters may be of unequal length. Asynchronous 
transmission most commonly occurs over terminal lines. 

bandwidth: The range of frequencies assigned to a channel or system (that is, the 
difference expressed in Hertz between the highest and lowest frequencies of a band). 

bilateral closed user group (BCUG): An optional packet switching data network 
(PSDN) facility that restricts a pair of DTEs to communicating with each other. 

broadcast addressing: A special type of multicast addressing, in which all nodes are 
to receive a message. 

broadcast circuit: A circuit on which multiple nodes are connected and on which a 
message can be transmitted to multiple receivers. 

carrier sense: A signal provided by the Physical layer to indicate that one or more 
stations (nodes) are currently transmitting on the Ethernet channel. 

Carrier Sense, Multiple Access with Collision Detect (CSMA/CD): A link 

management procedure used by the Ethernet. Allows multiple stations to access the 
broadcast channel at will, avoids contention by means of carrier sense and deference, 
and resolves contention by means of collision detection and retransmission. 
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CCITT: Comite Consultatif International Telegraphique et Telephonique. An 

international consultative committee that sets international communications usage 
standards. 

channel: A means of transmission. For VAX PSI, a logical path between a DTE and 
a DCE over which data is transmitted. Each channel is identified by a unique 
reference number called a logical channel number (LCN). 

characteristics: A display type for the SHOW and LIST commands. It refers to static 
information about a component that is kept in either the volatile or permanent 
database. Such information may include parameters defined for that component by 
either the SET or DEFINE command. 

circuit: Virtual communication path between nodes or DTEs. Circuits operate over 
physical lines and are the medium on which all I/O occurs. X.25 circuits are virtual 
circuits. 

closed user group (CUG): An optional PSDN facility that restricts two or more DTEs 
in the same group to communicating with each other. 

collision: Multiple transmissions overlapping in the physical channel, resulting in 
garbled data and necessitating retransmission. 

collision detect: A signal provided by the Physical layer to the Data Link layer to 
indicate that one or more stations (nodes) are contending with the local station's 
transmission. 

command node: The node from which an NCP command is issued. 

component: An element in the network that can be controlled and monitored. 
Components include lines, circuits, nodes, modules, logging, and objects. 
Components form part of the NCP command syntax. 

configuration database: The combination of both the permanent and the volatile 
databases. It consists of information about the local node, and all nodes, modules, 
circuits, lines, and objects in the network. 

congestion loss: A condition in which data packets are lost when Routing is unable 
to buffer them. 

connector node: A node which serves as an X.25 gateway to permit VAX/VMS host 
nodes to access a packet switching data network. 

control station: The node at the controlling end of a multipoint circuit. The control 
station controls the tributaries for that circuit. 

cost: An integer value assigned to a circuit between two adjacent nodes. According to 
the routing algorithm, packets are routed on paths with the lowest cost. 

counters: Performance and error statistics kept for a component, such as lines or 
nodes. 

data circuit-terminating equipment (DCE): A CCITT X.25 term referring to the 
network equipment that establishes, maintains and terminates a connection and 
handles the signal conversion and coding between the data terminal equipment and 
the network. The switching exchange of the network to which DTEs are connected. 
(In non-X.25 usage, the term is synonymous with modem.) 
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data link mapping (DLM): Capability of using an X.25 virtual circuit as a DECnet data 
link. 

data terminal equipment (DTE): An X.25 term referring to the user's equipment 
(computer or terminal) connected to a DCE on a packet switching data network for 
the purpose of sending and/or receiving data. 

datagram: A unit of data sent over the network that is handled independently of 
all other units of data so far as the network is concerned. When a route header is 
added, a datagram becomes a packet. 

designated router: A routing node on the Ethernet selected to perform routing 
services on behalf of end nodes. 

disconnect abort: Nontransparent tasks can deaccess a logical link via a disconnect 
abort operation without deassigning the channel. This form of disconnection 
indicates to the receiver that not all messages sent have necessarily been received. 

downline system load: A DECnet-VAX function that allows an unattended target 
node to receive an operating system file image from another node. 

downline task load: A function that allows a remote target node to receive an 
RSX-11S task from another node. 

end node: A node that can receive packets addressed to it and send packets to other 
nodes, but cannot route packets through from other nodes. Also called a nonrouting 
node. 

event: A network or system-specific occurrence for which the logging component 
maintains a record. 

event class: A particular classification of events. Generally, this classification follows 
the DNA architectural layers; some layers may contain more than one class. Class 
also includes the identification of system-specific events. 

event type: A particular form of event that is unique within an event class. 

executor node: The node at which an NCP command actually executes. 

frame: A unit delimited by flags that includes a header, and is used by the link level 
to exchange packets as well as control and error information between the DTE and 
the DCE on a packet switching data network. 

handshaking sequence: The exchange of logical link connection information between 
two tasks. This exchange takes place to enable the successful completion of a logical 
link connection. 

hardware address: For an Ethernet device, the unique Ethernet physical address 

associated with a particular Ethernet communications controller (usually in read-only 
memory) by the manufacturer. 

hop: The logical distance between two nodes. One hop is the distance from one node 
to an adjacent node. 

host node: For DECnet, a node that provides services for another node (for example, 
the host node supplies program image files for a downline load). 

For VAX PSI, a node that accesses a packet switching data network by means of an 
X.25 multihost connector node. 
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inbound connection: The term refers to the fact that a task receives logical link 
connection requests. 

interrupt: For VAX PSI, a packet, sent through a PSDN, that bypasses normal flow 
control procedures used by data packets. 

interrupt message: During nontransparent task-to-task communication, a user¬ 
generated message sent outside the normal exchange of data messages. This usage 
of the term interrupt is contrary to the normal usage, which means to designate a 
software or hardware interrupt mechanism. 

known component: The classification for one or more of the same components. This 
classification includes all active and inactive occurrences of the component type. For 
example, known nodes include all active and inactive nodes in the network. 

level 1 router: A node that can send and receive packets, and route packets from one 
node to another, only within a single area. 

level 2 router: A node that can send and receive packets, and route packets from one 
node to another, within its own area and between areas. Also known as an area 
router. 

line: The network management component that provides a distinct physical data path. 

Link Access Protocol (LAP): A set of procedures used for link control. X.25 defines 
two sets of procedures: 

• LAP—The DTE/DCE interface is defined as operating in two-way simultaneous 
Asynchronous Response Mode (ARM) with the DTE and DCE containing a 
Primary and Secondary function. 

• LAPB—The DTE/DCE interface is defined as operating in two-way 
Asynchronous Balanced Mode (ABM). 

In addition, LAPB with extended sequence numbering (that is, frame numbering 
modulo 128) is known as LAPBE. 

local node: The node at which you are physically located. 

logical channel: A logical link between a DTE and its DCE. The physical 
communications line between a DTE and DCE is divided into a set of logical 
channels. 

logical channel number (LCN): A unique reference number that identifies a logical 
channel. A DTE recognizes a virtual circuit by its associated LCN. 

logical link: A carrier of a single stream of full-duplex traffic between two user-level 
processes. 

logging: The network management component that routes event data to a logging sink 
such as a console or file. 

logging console: A logging sink that is to receive a human-readable record of events. 
Typically, a logging console is a terminal or a user-specified file. 

logging file: A logging sink that is to receive a machine-readable record of events for 
later retrieval. The logging file is user defined. 
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logging monitor: A logging sink that is to receive a machine-readable record of 
events for possible real-time decision making. Typically, the logging monitor is a 
user-defined program. 

loop node: A local node that is associated with a particular line and is treated as if it 
were a remote node. All traffic to the loop node is sent over the associated line. 

maximum visits: The maximum number of nodes through which a packet can be 
routed before reaching its destination. 

module: A network management component. 

multiaccess channel: A medium (for example, Ethernet) on which many transmitters 
contend for access. 

multicast addressing: An addressing mode in which a given message packet is 
targeted to a group of logically related nodes. 

multicast group address: An address assigned to a number of nodes on an Ethernet 
and used to send a message to all nodes in the group in a single transmission. 

multipoint circuit: A circuit connecting two systems, with one of the systems (the 
control station) controlling the circuit, and the other system serving as a tributary. 

network connect block (NCB): For DECnet, a user-generated data structure used in a 
nontransparent task to identify a remote task and optionally send user data in calls 
to request, accept, or reject a logical link connection. 

For VAX PSI, a block that contains the information necessary to set up an X.25 
virtual circuit or to accept or reject a request to set up an X.25 virtual circuit. 

network status notifications: Notifications that provide information about the 
state of both logical and physical links over which two tasks communicate. A 
nontransparent task can use this information to take appropriate action under 
conditions such as third-party disconnections and a partner's exiting before I/O 
completion. 

network task: A nontransparent task that is able to process multiple inbound 
connection requests; that is, it has declared a network name or object number. 

node: A network management component that supports DECnet software. 

node address: The required, unique, numeric identification of a specific node in the 
network. 

node name: An optional alphanumeric identification associated with a node address 
in a strict one-to-one mapping. A node name must contain at least one alphabetic 
character. 

nonprivileged: In DECnet-VAX terminology, this term means no privileges other than 
NETMBX and TMPMBX. NETMBX is the minimal requirement for any network 
activity. 

nonrouting node: An end node. 
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object: A DECnet-VAX process that receives a logical link request. It performs a 
specific network function (a nonzero object such as FAL or NML), or is a user- 
defined image for a special-purpose application (a zero-numbered object). 

A VAX PSI management component that contains records to specify account 
information for incoming calls and to specify a command procedure that is initiated 
when the incoming call arrives. 

outbound connection: The term refers to the fact that a task sends logical link 
connection requests. 

packet: A unit of data to be routed from a source node to a destination node. For 
VAX PSI, the unit of data switched through a PSDN; normally a user data field 
accompanied by a header carrying destination and other information. 

packet assembly/disassembly (PAD) device: A device at a PSDN node that allows 
access from an asynchronous terminal. The terminal connects to the PAD and the 
PAD puts the terminal's input data into packets (assembles) and takes the terminal's 
output data out of packets (disassembles). 

packet switching: A data transmission process, utilizing addressed packets, whereby 
a channel is occupied only for the duration of transmission of the packet. 

packet switching data network (PSDN): A set of equipment and interconnecting 
links that provides a packet-switching communications service to subscribers. 

Packetnet System Interface (PSI): The name for the software product that allows 
DIGITAL operating systems to participate in a packet-switching environment. 

parameter: An entry in the volatile or permanent database for a network management 
component. 

path: The route a packet takes from source to destination. 

path cost: The sum of the circuit costs along a path between two nodes. 

path length: The number of hops along a path between two nodes; that is, the number 
of circuits a packet must travel along to reach its destination. 

permanent database: A file containing information about network management 
components. 

permanent virtual circuit (PVC): A permanent logical association between two DTEs 
which is analogous to a leased line. Packets are routed directly by the network from 
one DTE to the other. 

physical address: The unique address value associated with a given system on an 
Ethernet circuit. An Ethernet physical address is defined to be distinct from all other 
physical addresses on an Ethernet. 

point-to-point circuit: A circuit that connects two nodes, operating over a single line. 

polling: The activity that the control station performs with a multipoint circuit's 
tributaries to grant the tributaries permission to transmit. 

privileged: In DECnet-VAX terminology, this term means any user privileges in 
addition to NETMBX and TMPMBX. 

protocol: An agreed set of rules governing the operation of a communications link. 
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proxy login: The procedure that permits a remote user to access a specific account at 
the local node, without supplying the user name and password. 

reachable node: A node to which the local node has a usable communications path. 

remote DTE: Any DTE in a network other than the one at which the user is located. 

remote node: To any one node in the network, this node is any other network node. 

router: A node that can send and receive packets, and route packets from one node to 
another. 

routing: The network function that determines the path along which data travels to its 
destination. 

routing node: A router. 

sink node: A node where logging sink types, such as a file or console, are actually 
located. 

source task: The task that initiates a logical link connection request in a task-to-task 
communication environment. 

state: The functions that are currently valid for a given component. States include 
line, circuit, local node, module, DTE, and logging. 

status: A display type for the SHOW and LIST commands. Status refers to dynamic 
information about a component that is kept in either the volatile or permanent 
database. 

substate: An intermediate circuit state that is displayed for a circuit state display via 
the SHOW or LIST command. 

summary: The default display type for the SHOW and LIST commands. A summary 
includes the most useful information for a component, selected from the status and 
characteristics information. 

switched virtual circuit (SVC): A temporary logical association between two DTEs 
connected to a PSDN, which is analogous to connection by a dialup line. An SVC is 
set up only when there is data to transmit and is cleared when the data transfer is 
complete. 

synchronous disconnect: The disconnect that occurs when a nontransparent task 
issues a call to terminate I/O operations over a logical link without deassigning the 
channel. Thus, the task can use the channel for subsequent I/O operations with the 
same or a different remote task. 

synchronous transmission: A mode of data transmission in which the time of 
occurrence of each signal representing a bit is related to a fixed time frame. 

target node: The node that receives a memory image during a downline load; a node 
that loops back a test message. 

target task: The task that receives and processes a logical link connection request in a 
task-to-task communication environment. 

task: In this manual, the term refers to an image running in the context of a process. 
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task specifier: Information provided to DECnet-VAX software so that it can complete 
a logical link connection to a remote task. This information includes the name of the 
remote node on which the target task runs and the name of the task itself. 

terminal emulator: A program that acts as a transparent interface between two ports, 
making it appear as though a terminal on the local processor is directly connected to 
a remote processor. 

tributary: A physical termination on a multipoint circuit that is not a control station. 

tributary address: A numeric address that the control station uses to poll a tributary. 

upline dump: A DECnet-VAX function that allows an adjacent unattended node to 
dump its memory to a file on a VAX/VMS system. 

virtual circuit: An association between two nodes (or two DTEs connected to a 
PSDN) whereby the two nodes (or DTEs) are able to interact as if a specific 
circuit were dedicated to them throughout the transmission. In reality a logical 
connection is established, the actual physical circuits being allocated according to 
route availability, overload conditions, and so on. 

virtual terminal: A pseudodevice which connects a process to a physical terminal 
device. The virtual terminal can be disconnected from the physical terminal and 
reconnected later. 

volatile database: A memory image that contains information about network 
management components. 

window: A range of packets authorized for transmission across an X.25 DTE/DCE 
interface. The lowest sequence number in the window is referred to as the lower 
window edge (0 when the virtual circuit is just established). The packet send 
sequence number of the first data packet not authorized to cross the interface is the 
value of the upper window edge (that is, the lower window edge plus the window 
size). 

X.3: A CCITT recommendation that specifies the packet assembly/disassembly (PAD) 
facility in a public data network. 

X.25: A CCITT recommendation that specifies the interface between data terminal 
equipment and data circuit-terminating equipment for equipment operating in the 
packet mode on public data networks. 

X.28: A CCITT recommendation that specifies the DTE/DCE interface for a start-stop 
mode DTE accessing the packet assembly/disassembly (PAD) facility in a public 
data network situated in the same country. 

X.29: A CCITT recommendation that specifies procedures for the exchange of control 
information and user data between a packet-mode DTE and a packet 
assembly/disassembly (PAD) facility. 

X.29 terminal: A terminal connected to a packet assembly/disassembly (PAD) facility. 
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definition • 2-22 
leakage* A-14 

number*2-2, 2-21, 2-22, 3-7, 3-61 
number in Ethernet address *3-12 
partitioning • A-10 
path control parameters • 3-65 
Area leakage problem* A-14 
AREA MAXIMUM COST parameter • 3-65 
AREA MAXIMUM HOPS parameter • 3-65 


Index—1 










Index 


Area router 

See Level 2 router 
Area routing* 1-2, 2-20 
advantages *2-22 
alternate paths *A-3 
avoiding problems* A-10 
concepts* 2-22 
configuration guidelines • A-2 
converting to multiple areas* A-8 
design considerations* A-1 
design redundancy • A-2 
dropping area number* A-12 
example of configuration procedure • A-5 
leakage problem* A-2, A-14 
limiting number of areas *3-62 
on Ethernet • 2-25, A-15 
partitioned area problem* A-10 
Phase III node problem* A-12 
techniques* A-1 

ASSISTANT PHYSICAL ADDRESS parameter* 
7-11 

ASTLM quota *5-34 
Asynchronous circuit 
See Circuit 
See DDCMP 

Asynchronous connection 
DDCMP* 1-8 
dynamic* 1-4, 1-7, 1-8 
line parameters*3-56 
static* 1-4, 1-7, 1-8 
Asynchronous line 
See DDCMP 
See Line 

Asynchronous terminal 
See X.29 terminal 
AUTHORIZE command *5-4 
AUTOGEN facility *5-32 
AUTO prefix *3-36 


B 


Babble timer*3-40 
Base priority of circuit *3-39 
BCUG (bilateral closed user group) *2-6, 3-30, 
3-75 

Bilateral closed user group 
See BCUG 
BIOLM quota *5-34 
Bootstrap 

primary *4-2, 4-13 


Bootstrap (cont'd.) 

ROM • 4-3 

Broadcast address* 1-7, 3-13 
Broadcast routing timer *2-27 
BROADCAST ROUTING TIMER parameter • 3-66 
Buffer size 

changing for executor • 3-18 
decreasing *3-18 
for executor*2-3 
for line*3-17, 3-53 
increasing *3-18 
requirements *3-17 
setting for executor • 3-8, 3-17 
BUFFER SIZE parameter 
for executor • 3-8, 3-17 
for line*3-53 
BYPASS privilege* 5-2 
BYTLM quota *5-34 


c 


Call 

destination of X.25 call *2-32 
DLM incoming and outgoing • 3-45 
outgoing from DTE *3-26 
Call handler 

server module *2-32 
CALL MASK parameter 

for incoming X.25 calls *3-76 
Call redirection facility • 3-77 
CALL TIMER parameter • 3-28 
CALL VALUE parameter 

for incoming X.25 calls *3-76 
Carrier Sense Multiple Access with Collision Detect 
See CSMA/CD 

Carrier sense on Ethernet* 1-6 
CCITT recommendation* 1-3, 1-12 
Channel *8-10 

assigning for logical link *8-10, 8-18, 8-29 
deassignment of *8-13, 8-17 
_NET: • 8-23 

Channel, communications* 1-5, 1-7 
CHANNEL parameter 
for PVC • 3-43 
CHANNELS parameter 
for DTE *3-26 

CHARACTERISTICS display type *3-91 
Checkpointing RSX-1 IS tasks*4-20 
Cl (computer interconnect) 
as DECnet line* 5-7 
as VAXcluster connector* 1-10 
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Cl (computer interconnect) (cont'd.) 
as VAXcluster data link* 1-10, 2-25 
cable* 1-10 
circuit* 2-6 
circuit device *2-10 
configuration • 1 -4 
controller* 2-10 
driver • 2-10 
end node*2-25 

end node backup circuit• 2-25, 3-66 

line *2-12 

line device*2-17 

node addressing • 3-32 

router* 2-25 

CI-750 device *2-10, 2-12 

Cl—780 device *2-10, 2-12 

Circuit* 1-1, 1-19 

asynchronous DDCMP devices *2-8 
Cl *2-6 

commands* 3-31 
cost *2-26, 3-62 
counters* 3-47 
database • 3-1 
DDCMP* 1-8, 2-6, 3-33 
definition • 2-6 
determining cost *3-63 
device name *3-31 
DLM* 1-1, 2-11, 3-33, 3-44 
dynamic asynchronous • 2-8 
Ethernet* 1-6, 2-6, 3-33 
identification *3-31, 3-33 
loopback test*7-6 
multiaccess* 2-6 
multipoint control *2-6 
multipoint tributary • 2-6 
name • 2-7 
parameters *3-33 
point-to-point • 2-6 
polling • 3-39 
service • 4-2 

service operations • 3-37 

setting base priority • 3-39 

state*2-7, 3-36 

static asynchronous* 1-9 

synchronous DDCMP devices *2-7 

timers • 3-37 

types *3-33 

verification • 3-37 

virtual* 1-1, 1-3, 1-6, 1-8 

X.25* 2-6, 2-11, 3-33, 3-43 

Circuit-level loopback test *7-1 
Ethernet* 7-9 

CLEAR EXECUTOR command *3-17 


CLEAR NODE command • 3-17, 7-3 
CLEAR TIMER parameter • 3-28 
Closed user group 
See CUG 

Cluster alias node identifier 
See Alias node identifier 
CMKRNL privilege *5-2 
CNDRIVER • 5-3, 5-7 
Code 

system service status return *8-17, 8-29 
Collision detect 
Ethernet* 1-6 
Command 

NCP command verbs *3-3 
NCP functions • 3-3 
remote execution of *3-5 
syntax • 3-4 
Command node *4-1 
Command procedure 

See also DCL command procedure 
for object • 3-72 
identification • 3-72 

Command terminal, heterogeneous • 8-1 
Communication 

task-to-task • 1-3, 1-20, 8-1 
Component name 
plural forms *3-91 
Components* 3-1 
Computer interconnect 
See Cl 

Configuration 

automatic* 1-17 
Cl* 1-4 
database 

See Configuration database 
end node*2-21 
Ethernet* 1-4, 1-5 
for area routing* A-1 
guidelines for area routing* A-2 
guidelines for system *5-31 to 5-38 
multipoint* 1-4, 1-7 
NETCONFIG.COM* 1-17, 5-4 to 5-7 
network • 1-4, 5-1 

of a DDCMP dynamic asynchronous network* 
5-18 

of a DDCMP multipoint network *5-15 

of a DDCMP point-to-point network *5-13 

of a DDCMP static asynchronous network *5-17 

of a DECnet-VAX node *1-17 

of a DLM (data link mapping) network *5-22 

of a multiple-area network* 1-2, A-2 

of an Ethernet network *5-21 
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Configuration (cont'd.) 

of an X.25 multihost mode network*5-26 
of an X.25 multinetwork connection • 5-30 
of an X.25 native mode network *5-25 
of a PSI DTE* 1-16, 1-17, 2-5 
of a single-area network* 1-2 
point-to-point • 1-4, 1-7 
prerequisites* 5-1 
procedure examples*5-12 to 5-29 
procedure for automatic • 5-4 to 5-7 
required privileges* 5-2 
routing considerations*2-19 
sample Phase IV DECnet-VAX* 1-5 
typical VAXcluster* 1-10 
VAX PSI* 1-4, 5-1 

Configuration database • 2-1, 3-1, 5-4, 5-13 
circuit entry • 2-7 
DECnet-VAX* 1-17, 3-1 
line entry • 2-12 
logging entry *2-35 
node entry *2-2, 3-4 
VAX PSI* 1-17, 3-3 
X.25 access module entry *2-6 
X.25 protocol module entry *2-5 
X.25 server module entry *2-32 
Configurator module 

disabling surveillance*3-43 
enabling surveillance • 3-41 
Ethernet* 1-19, 2-10, 3-41 
NICONFIG* 1-15 

CONNECT NODE command *4-21 

PHYSICAL ADDRESS parameter *4-21 
SERVICE CIRCUIT parameter • 4-21 
SERVICE PASSWORD parameter • 4-21 
Connector node 
See X.25 

CONNECT VIA command *4-21 
Control 

of line traffic • 3-52 

of logical link activity • 2-28, 3-67 

of tributaries *3-39 

station • 1-7, 2-8 

Controller loopback test *7-6, 7-8 
Copying node database* 1-17, 2-3, 3-20 
COPY KNOWN NODES command *3-20 
FROM parameter *3-21 
TO qualifier *3-21 
USING qualifier • 3-21 
WITH CLEAR qualifier • 3-21 
WITH PURGE qualifier *3-21 
Cost 

circuit • 3-62 

control for circuit *2-26 


Cost (cont'd.) 

determining for circuit *3-63 
for routing • 2-25 
COST parameter 
for circuit *3-62 
Counters 

circuit *3-47 
line *3-59 
logging *3-24 
node *3-24 

X.25 protocol module *3-31 
zeroing *3-24 

COUNTERS display type *3-91 
Counter timer*3-24 
COUNTER TIMER parameter 
for circuit *3-47 
for executor *3-24 
for node*3-24 
CPU (central processing unit) 

identification for downline load *4-12 
time requirements*5-35 
CSMA/CD • 1-6 

CUG (closed user group) *2-6, 3-30, 3-75 


D 


Database 
circuit *3-1 

clearing or purging before copying node entries* 
3-21 

configuration 

See Configuration database 
copying node* 1-17, 2-3, 3-20 
DECnet-VAX* 1-17 
line • 3-1 
logging *3-1 
module*3-1, 3-3 
node* 3-1 
object*3-2, 3-3 
permanent* 1-16, 3-2, 5-38 
VAX PSI* 1-16, 3-3 
volatile* 1-16, 3-2 
Data circuit-terminating equipment 
See DCE 
Datagrams 

Ethernet* 1-6 

Data link control *2-3, 3-17 
Data link mapping 
see DLM 

Data network* 1-1 
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Data terminal equipment 
See DTE 

DCE (data circuit-terminating equipment) • 1-12 
DCL command procedure*8-4, 8-37 

example for task-to-task operations • 8-37 
for starting object *8-37 
DCL commands* 1-21 

DDCMP (DIGITAL Data Communications Message 
Protocol) • 1-4 

asynchronous* 1-4, 1-7, 2-8, 2-12, 3-32, 5-8 

asynchronous line* 1-5, 3-49 

circuit *2-6, 3-31, 3-33 

configuration • 1-7 

CONTROL line *3-49 

DMC line *3-49 

dynamic asynchronous network configuration* 
5-18 

formula for determining maximum number of 
messages *3-55 
line*2-12, 3-50 
MOP *4-14 
multipoint* 1-7 

multipoint network configuration • 5-15 
multipoint tributary addressing • 3-32 
POINT line *3-49 
point-to-point* 1-7 
point-to-point addressing • 3-32 
protocol* 1-8 

static asynchronous network configuration* 
5-17 

synchronous* 1-4, 1-7, 2-7, 2-12 
synchronous devices* 1-8 
synchronous line* 1-5 
synchronous point-to-point network 
configuration *5-13 
TRIBUTARY line *3-49 
DEAD THRESHOLD parameter • 3-39 
Dead timer*3-54 
DECnet-VAX 

configuration database* 1-14 

configuration on a VAX/VMS system* 1-2 

configuration on a MicroVMS system* 1-2 

configuration prerequisites • 5-1 

functions* 1-3 

host services* 1-3, 1-14 

over terminal lines *5-7 

over the Cl • 5-7 

software* 1-15 

DECnet-VAX license* 1-15, 2-21 
end node kit* 1-15, 6-1 
full function kit* 1-15, 6-1 
installing the key* 1-15, 5-6, 6-1 


DECS A (DIGITAL Ethernet Communications Server) 
connection to remote console *4-20 
DEFAULT ACCESS parameter • 3-88 
SET EXECUTOR command *2-40 
DEFAULT DATA parameter 
for X.25 circuit *3-27 
Default DECnet account 

See Default nonprivileged DECnet account 
Default nonprivileged DECnet account 
creation by NETCONFIG.COM • 5-1, 5-5 
example* 5-1 

use in access control • 2-39, 3-87 
DEFAULT PROXY parameter • 3-89 
SET EXECUTOR command *2-41 
DEFAULT WINDOW parameter 
for X.25 circuit *3-27 
DEFINE EXECUTOR command 
TYPE parameter *3-60 
DEFINE NODE command *5-4 
Delay timer • 3-54 
DELUA 
See UNA 

DELUA communications controller*2-18, 3-11 
DEQNA 
See QNA 

DEQNA communications controller* 1-6, 2-18, 
3-11 

Designated router 
See Ethernet 
Destination 

of X.25 call *2-32 
DESTINATION qualifier • 3-74 
DETACH privilege*5-2 
DEUNA 
See UNA 

DEUNA communications controller* 1-6, 2-18, 

3-11 
Device 

CI-750*2-10, 2-12 
Cl—780* 2-10, 2-12 
DHU11 asynchronous • 2-8, 2-12 
DHV11 asynchronous • 2-8, 2-12 
DMC1 1 • 1-8, 2-7, 2-12 
DMF32 • 1-8, 2-7, 2-12 
DMF32 asynchronous *2-8, 2-12 
DMP1 1 • 1-8, 2-7, 2-12 
DMR11 • 1-8, 2-7, 2-12 
DM VI 1*2-7 

DMZ32 asynchronous*2-8, 2-12 
DPV1 1*2-18 
DUP11-DA *2-18 
DZ1 1 • 1-8 
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Device (cont'd.) 

DZ11 asynchronous *2-8, 2-12 

DZ32 asynchronous*2-8, 2-12 

DZV11 asynchronous*2-8, 2-12 

KMS11-BD* 2-18 

KMS1 1-PX *2-18 

KMS1 1-PY *2-18 

KMV1 1*2-18 

KMY *2-18 

QNA *2-10, 2-18 

UNA *2-10, 2-18 

DHU1 1 asynchronous device *2-8, 2-12 
DHV11 asynchronous device *2-8, 2-12 
DIAGNOSE privilege*5-2 
Dialup line* 5-8 

DIGITAL Network Architecture 
See DNA 

DIOLM quota *5-34 
Disconnect • 8-13 
abort *8-13, 8-28 
synchronous *8-13 
DISCONNECT LINK command *3-67 
Display type 

CHARACTERISTICS • 3-91 
COUNTERS *3-91 
EVENTS *3-91 
STATUS *3-91 
SUMMARY *3-91 

DLM (data link mapping)* 1-1, 1-3, 1-12 
circuit* 1-1, 2-7, 2-11, 3-33 
CIRCUIT parameters *3-44 
incoming and outgoing calls *3-45 
network configuration • 5-22 
OWNER EXECUTOR circuit parameter*3-45 
setting up a circuit *3-47 
subaddresses • 3-46 
DMC11 device* 1-8, 2-7, 2-12 
DMF32 asynchronous device *2-8, 2-12 
DMF32 device* 1-8, 2-7, 2-12 
DMP11 device* 1-8, 2-7, 2-12 
DMR11 device* 1-8, 2-7, 2-12 
DM V11 device *2-7 

DMZ32 asynchronous device *2-8, 2-12 
DNA (DIGITAL Network Architecture) 
layers* 1-4 
protocols* 1-4 
Downline system load 

default loader files *4-13 
definition *4-1 
load requirements *4-5 
load sequence *4-4 
network example *5-13 


Downline system load (cont'd.) 
operator-initiated *4-1, 4-5 
over DDCMP circuit *4-6 
over Ethernet *4-2, 4-6 
target-initiated • 4-2 
unattended systems *4-1 
Downline task load *4-16 
DPV11 device *2-18 

DTE (data terminal equipment)* 1-12, 2-5 
address* 2-5 
bringing up *6-2 

configuration* 1-16, 1-17, 2-5, 6-2 
definition *2-1 

handling incoming calls *2-33 
handling outgoing calls *3-26 
subaddress *3-75 
DTE parameter 
for GROUP *3-30 
for PVC*3-43 
DTE qualifier 

CHANNELS parameter • 3-26 
LINE parameter*3-26 
MAXIMUM CIRCUITS parameter • 3-26 
SET MODULE X25-PROTOCOL command *3-25 
STATE parameter*3-25 
DTR (DECnet Test Receiver) • 2-29 
DUMP ADDRESS parameter *4-14 
Dump assistance multicast address *4-15 
DUMP COUNT parameter *4-14 
DUMP FILE parameter *4-14 
Dumping unattended system memory *4-14 
DUP11-DA device *2-18 
Duplex mode *3-54 
DUPLEX parameter *3-54 
DYING BASE parameter • 3-39 
DYING INCREMENT parameter • 3-39 
DYING THRESHOLD parameter • 3-39 
Dynamic allocation of map registers and device 
drivers* 5-36 

Dynamic asynchronous circuit *2-8 

VERIFICATION INBOUND parameter • 3-38, 

3-86 

Dynamic asynchronous connection* 1-4, 1-7 
network configuration • 5-18 
password • 2-36 
reasons for failure *5-11 
Dynamic asynchronous line* 1-9, 2-14, 5-8 
HANGUP parameter*3-56 
installing *5-10 
LINE SPEED parameter*3-56 
shutting down *5-12 
SWITCH parameter • 3-56 
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Dynamic switching 

manual switching of line *2-17 
procedure for line *2-14 
setting up lines • 5-10 
DYNSWITCH image*2-16 
installing *5-10 

DZ1 1 asynchronous device *2-8, 2-12 
DZ1 1 device* 1-8 

DZ32 asynchronous device *2-8, 2-12 
DZV11 asynchronous device *2-8, 2-12 


E 


End node* 1-1, 1-15 

caching on Ethernet • 2-24 
configuration • 2-21 
DECnet-VAX license kit* 1-15, 6-1 
definition *2-19 
Ethernet* 1-7, 2-24 
non-Ethernet* 1-7 
on VAXcluster* 1-11 
Phase IV *2-21 
ENQLM quota • 5-34 
Error messages 
HLD *4-19 

loopback testing • 7-6 
Error reporting• 8-17, 8-29 

system service status*8-17, 8-29 
Ethernet* 1-5 

address conversion • 3-61 
address format *3-1 1 
adjacent node *2-7 
area number in address *3-12 
area routing on*2-25, A-15 
broadcast address* 1-7, 2-3 
broadcast routing timer *3-66 
cable* 1-6 
carrier sense* 1-6 
characteristics* 1-6 
circuit* 1-4, 1-6, 2-6, 3-33 
circuit device* 1-6, 2-10 
circuit identification • 3-33 
circuit parameters • 3-40 
configuration • 1-4, 1-5 

configurator module* 1-15, 1-19, 2-10, 3-41 

datagrams* 1-6 

data link for VAXcluster* 1-10 

data rate • t -6 

designated router* 1-7, 2-19, 2-24, 3-40 
determining physical address *3-12 
displaying physical address *3-12 


Ethernet (cont'd.) 

downline system load *4-6 

dump assistance multicast address *4-15 

end node* 1-7, 2-24, 3-40 

end node caching *2-24 

hardware address• 2-18, 3-1 1, 3-57, 7-9 

limiting end nodes *3-62 

limiting routers *3-61 

line* 2-12 

line device*2-18 

line parameters*3-57 

line protocol • 3-49 

multiaccess* 1-6 

multicast address* 1-7, 2-3 

multicast address definition • 3-13 

multicast address values *3-13 

network configuration • 5-21 

node* 1-6 

node address *2-2, 3-1 1 
node number in address *3-12 
non-DECnet application • A-10 
packets* 1-6 

physical address* 1-7, 2-2, 2-7, 2-18, 3-11, 
4-6, 7-9 

physical address definition • 3-13 
physical address values *3-13 
protocol • 1-5, 2-7 
resetting physical address *3-1 1 
router* 1-7, 2-24, 3-40 
service operations • 3-36 
specification • 1-5 
topology* 1-6 
upline memory dump *4-15 
Ethernet loopback test *7-9 
to remote system • 7-9 
UNA device • 7-9 
Event 

class • 3-82 
definition • 2-34 
identification • 3-82 
identifying location of *3-83 
list *2-34 
sink-related • 2-34 
source* 3-83 
source-related • 2-34 
type • 3-82 
Event logger 
See EVL 

Event logging example *3-84 

EVENTS display type *3-91 

EVL (event logger) • 1-15, 2-29, 2-34 
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Executor node *2-2, 4-1 
commands* 3-5 


F 


FAL (file access listener)* 1-15, 2-29 
File 

default access control* 1-23 
logical name in specification* 1-25 
manipulation over the network* 1-20 
specification • 1-23 

specification access control string* 1-23 
specification over the network* 1-23 
File access 

over network* 1-3 
remote* 1-20 

File access listener* 1-15, 2-29 
FILE parameter 

for DECnet-VAX command procedure • 3-73 
FILLM quota *5-34 
Frame control 

X.25 lines*3-57 
FROM parameter 

COPY KNOWN NODES command *3-21 


Hello timer *3-37 
HELP parameter 

LOOP CIRCUIT command *7-11 
Heterogeneous command terminal* 1-3, 1-21,8-1 
Heterogeneous network 
remote file operations*9-1 
Higher-level language statements* 1-21 
HLD (host loader)* 1-16, 2-29, 4-16 
mapping table *4-18 
HLDTBS *4-18 
HNODE$ *4-18 
Hop *2-25 
Host identification 

for downline task load *4-10 
Host loader 
See HLD 
Host node 

for X.25 connection* 1-3, 3-78, 3-79 
Host services 

DECnet-VAX* 1-3, 1-14, 4-1 
on Ethernet *2-3 
HTASKS *4-18 


i 


G 


Gateway node 
See X.25 
GROUP parameter 

for X25-SERVER module *3-75 
GROUP qualifier 

DTE parameter • 3-30 
for X25-PROTOCOL module *3-30 
NUMBER parameter • 3-30 
TYPE parameter*3-31 
Guidelines 

system configuration • 5-31 to 5-38 


H 


HANGUP parameter • 3-56 
Hardware address 
Ethernet *3-11 

HARDWARE ADDRESS parameter 
SET NODE command *4-8 
Hardware loopback device *7-6 


IAS node • 9-2 
Identification 

of circuits*3-31 
of events *3-82 
of lines *3-48 
of network *3-25 
of node address *2-2, 3-7 
of node name *2-2, 3-7 
of objects *3-70 
of X.25 connector node *3-80 
IDENTIFICATION parameter 
for local node*3-8 
INACTIVE BASE parameter • 3-39 
INACTIVE INCREMENT parameter*3-39 
INACTIVE THRESHOLD parameter • 3-39 
INACTIVITY TIMER parameter • 3-68 
Inbound logical link connection* 1-24 
INBOUND parameter 

SET NODE command *3-89 
Incoming calls to a DTE *2-33 
INCOMING TIMER parameter • 3-68 
Initialization 

of DDCMP node* 1-8 
of Ethernet node* 1-6 
of Phase III node*2-36, A-14 
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Installation 
network* 6-1 
VAX PSI • 6-2 

IRPCOUNT parameter* 5-32 
ISO networks • 3-30 


K 


Key 

DECnet-VAX license* 1-15, 2-21 
KMS11 

dumping microcode* 7-13 
KMS1 1-BD device *2-18 
KMS11-PX device *2-18 
KMS11-PY device *2-18 
KMS/KMV DUMP Analyzer 

See PSIKDA 
KM VI 1 

dumping microcode • 7-13 
KM V11 interface *2-18 
KMY interface *2-18 
KNOWN 

plural form of component name *3-91 


L 


LAN (local area network) 

Ethernet* 1-4 
LAPBE line 
See X.25 line 
LAPB line 

See X.25 line 

LCN (logical channel number) *3-26 
LEF (local event flag) state *8-16 
Level 1 router* 1-2, 2-19, 2-21, A-1 
Level 2 router* 1-2, 2-19, 2-21, A-1 
subnetwork • A-3 

LIB$ASN_WTH_MBX library routine• 8-1 1, 8-23 
License 

See DECnet-VAX license 
Line* 1-1 

asynchronous DDCMP devices *2-12 
buffers for DDCMP line *3-54 
buffer size • 3-53 
Cl• 2-12 

commands • 3-48 
counters* 3-59 
database* 3-1 


Line (cont'd.) 

DDCMP *2-12 
definition *2-11 
device name *3-48 
dialup* 5-8 

dynamic asynchronous* 1-9, 2-14, 5-8 
dynamic switching • 2-14 
Ethernet *2-12, 3-57 
identification • 3-48 

installing dynamic asynchronous • 5-10 

installing static asynchronous • 5-8 

LAPB *3-49 

LAPBE *3-49 

multipoint* 2-13 

name *2-12 

operational state *3-52 

parameters* 3-50 

point-to-point *2-13 

protocol • 3-49 

state *2-12 

static asynchronous* 1-9, 2-14, 5-8 
synchronous DDCMP devices *2-12 
terminal* 1-9 
timers *3-54 
types *3-50 
X.25*2-12 
LINE parameter 
for DTE *3-26 

LINE SPEED parameter *3-56 
Link 

See Logical link 
LIST command *3-90 
Load assistance multicast address *4-2 
Load file identification 
for downline load *4-10 
LOAD NODE command *4-2, 4-7 
HOST parameter *4-10 
overriding default parameters • 4-9 
SECONDARY LOADER parameter • 4-12 
SERVICE DEVICE parameter *4-13 
SERVICE PASSWORD parameter • 4-13 
SOFTWARE IDENTIFICATION parameter • 4-12 
SOFTWARE TYPE parameter *4-12 
TERTIARY LOADER parameter • 4-12 
LOAD VIA command *4-7 

PHYSICAL ADDRESS parameter• 4-8, 4-13 
SERVICE DEVICE parameter*4-13 
Local area network 
See LAN 

Local loopback test *7-5 
Local node* 1-14, 1-20, 2-2, 3-5 
operational state *3-20 
restrictions* 6-3 
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Local node (cont'd.) 
setting address *3-7 
states* 6-3 

Local-to-local loopback test *7-4 
Local-to-remote loopback test *7-3 
Logging* 1-19, 2-34 
commands *3-80 
console*2-35, 3-81 
database* 3-1 
file *2-35, 3-81 

monitor• 2-35, 3-81, 3-84 to 3-85 
parameters* 3-80 
sink *2-35, 3-81 
state *3-83 

Logical channel number 
See LCN 

Logical link* 1-1, 1-19, 8-7, 8-9, 8-10, 8-13, 8-16 
aborting • 8-9, 8-28 
access control information* 1-24 
assigning channel for*8-16, 8-29 
commands* 3-66 

completing connection of*8-1 1, 8-16, 8-26, 
8-31 

control • 2-28 
controlling activity • 3-67 
default access control information* 1-24 
definition • 2-27 

disconnecting • 2-28, 3-67, 8-9, 8-13, 8-28, 
8-34 

handshaking sequence*8-10 
inactivity timer *2-28 
inbound* 1-24, 3-67 
incoming timer *2-28 
maximum number *2-28, 3-67 
outbound* 1-24, 3-67 
outgoing timer *2-28 
parameters* 2-28 
protocol operation • 2-28 
protocol parameters*3-67 
rejecting a request *8-32 
requests*8-7, 8-10, 8-11, 8-16, 8-24, 8-26, 
8-30 

retransmission delay *2-28 
retransmission time *2-28 
SYS$NET *8-11 

terminating • 8-9, 8-13, 8-17, 8-21, 8-29 
timers *3-68 
Logical name 

as device name* 1-25 
as node name* 1-25 
in process logical name table* 1-25 
translation • 1-25 


Logical name (cont'd.) 

use in network application* 1-25 
LOGINOUT image*2-37, 2-39, 8-11, 8-26 
Loopback 

assistance* 7-11 
connector* 7-6 
Loopback mirror *7-2 
Loopback test 
circuit • 7-6 
circuit-level • 7-1 
controller* 7-6, 7-8 
local node*7-5 
local-to-local* 7-4 
local-to-remote • 7-3 
node-level • 7-1 
over Ethernet circuit *7-9 
software*7-6, 7-7 
to a remote node *7-2 
using a loop node name *7-2 
X.25 line-level *7-12 
LOOP CIRCUIT command *7-6 

ASSISTANT NODE parameter • 7-1 1 
ASSISTANT PHYSICAL ADDRESS parameter* 
7-11 

HELP parameter* 7-11 
NODE parameter*7-10 
PHYSICAL ADDRESS parameter* 7-10 
LOOP EXECUTOR command *7-5 
LOOP LINE command 

COUNT parameter* 7-13 
LENGTH parameter*7-13 
WITH parameter*7-13 
LOOP NODE command *7-2 
CIRCUIT parameter* 7-2 
Loop node name *7-2 
LRPCOUNT parameter*5-32 
LRPSIZE parameter*5-32 


M 


MACRO programs 

in network application* 1-21 
Mailbox *8-7, 8-23, 8-24 

creation of using SYSSCREMBX • 8-23 
message format • 8-24 
MAIL object *2-4, 2-29, 2-30, 3-71 
Maintenance operation protocol 
See MOP 

Maintenance operations over the network *4-1 
MAXIMUM ADDRESS parameter • 3-8 
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MAXIMUM AREA parameter*3-62 
MAXIMUM BLOCK parameter 
for X.25 line*3-58 

MAXIMUM BROADCAST NONROUTERS 
parameter 

for Ethernet circuits • 3-62 
MAXIMUM BROADCAST ROUTERS parameter 
for Ethernet circuits*3-62 
Maximum buffers 
for executor • 3-19 

MAXIMUM BUFFERS parameter*3-19, 3-40 
MAXIMUM CIRCUITS parameter 
for DTE *3-26 
for executor node *3-19 
for X.25 server module*3-78 
MAXIMUM CLEARS parameter • 3-28 
MAXIMUM COST parameter • 3-64 
MAXIMUM DATA parameter 
for PVC • 3-44 
for X.25 lines*3-57 
for X.25 virtual circuit*3-27 
MAXIMUM HOPS parameter • 3-64 
MAXIMUM LINKS parameter • 3-67 
MAXIMUM RECALLS parameter • 3-45 
MAXIMUM RESETS parameter • 3-29 
MAXIMUM RESTARTS parameter• 3-29 
MAXIMUM RETRANSMIT parameter • 3-57 
MAXIMUM ROUTERS parameter • 3-41 
for an Ethernet circuit *3-61 
MAXIMUM TRANSMITS parameter • 3-40 
Maximum visits *2-26 
MAXIMUM VISITS parameter• 3-64 
MAXIMUM WINDOW parameter 
for PVC *3-44 
for SVC *3-27 
for X.25 line*3-58 
Memory pool *5-32 
Memory requirements 
normal • 5-32 
worst-case • 5-34 
Message*8-7, 8-12, 8-19, 8-20 
data *8-12 

exchanging* 8-12, 8-17, 8-27 
interrupt• 8-7, 8-27 
mailbox* 8-7, 8-12 
network status *8-7 
optional user data *8-7, 8-10, 8-21 
Microcode* 1-8 

dumping KMS11*7-13 
dumping KMV1 1*7-13 
MICROCODE DUMP parameter • 7-13 


MicroVMS system 

as DECnet-VAX node* 1-2, 5-3 
MIRROR (loopback mirror)* 1-16, 2-29 
Mixed Phase Ill/Phase IV network* A-12 
Modem *5-8, 7-6 
Module* 1-19 
database *3-1 

Ethernet configurator* 1-19, 2-10, 3-41 
X.25 access* 1-19, 2-34, 3-79 
X.25 protocol* 1-19, 3-24 
X.25 server* 1-19, 2-32, 3-74 
X.25 trace* 1-19 
X.29 server* 1-19, 2-32, 3-74 
MOM subprocess of NML*4-2 
Monitor Utility (MONITOR) • 5-34 
MOP (maintenance operation protocol) • 4-2, 4-14 
error recovery *4-5 

request memory dump message *4-14 
Multiaccess 
circuit • 2-6 
Ethernet* 1-6 

Multicast address* 1-6, 1-7 
broadcast *3-13 
dump assistance *4-15 
Ethernet *3-13 
group *3-13 
load assistance *4-2 
Multihost connector node 
See X.25 

Multinetwork configuration • 5-30 
Multiple-area network* 1-2 
conversion to* A-8 
design of • A-2 

example of configuration • A-5 
example of design* A-3 
Multiple inbound connects• 8-7, 8-27, 8-36 
Multipoint 
circuit • 2-8 

configuration • 1-4, 1-7, 5-15 

control circuit *2-6 

control station *2-8 

line* 2-13 

polling • 2-8 

tributary • 2-8 

tributary address *2-8, 3-32 
tributary circuit *2-6 


N 


NAME parameter 

identifying logging device *3-81 
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NAME parameter (cont'd.) 

SET NODE command *3-7 
NCB (network connect block) *3-71, 8-10, 8-24 
destination descriptor • 8-25 
for incoming X.25 call *2-33 
NCP (Network Control Program)* 1-14, 1-16 
command functions • 3-3 
commands* 1-14 
command syntax *3-4 
command words *3-3 
definition • 3-3 

invalid grouping error message *3-16 
LIST command *3-90 
SHOW command *3-90 
specifying plural components • 3-4, 3-91 
tailoring the configuration database *5-7 
TELL prefix *3-6 
users* 1-14 
using commands *3-1 
_NET: • 8-23, 8-29 

NETACP (network ancillary control program)* 
1-16, 5-35 

NETCONFIG.COM *1-17, 3-2, 5-4 to 5-7 
creation of default nonprivileged DECnet 
account* 5-1 

supplying node address *5-5 
NETDRIVER (network driver) • 1-16, 5-35 
NETMBX privilege *2-38, 5-2 
NETNODE_LOCAL.DAT • A-8 
NETNODE_REMOTE.DAT • A-8 
NETSERVER 

See Network server process 
NETSERVER.LOG *4-19 
NETSERVERSTIMEOUT • 2-30 
NETUAF.DAT*2-37, 2-41 
Network 

access control *2-35 

access levels* 1-21 

bringing up *6-1 

configuration* 1-4, 5-1 

conversion to multiple-area network* A-8 

CPU time requirements • 5-35 

decentralized • 1-2 

displaying • 8-1 

example* 1-17 

identification • 3-25, 3-59 

ISO *3-30 

limiting number of areas *3-62 
monitoring • 3-90 
multinetwork • 5-30 
multinode* 1-2 
multiple-area • 1-2 
multiple-area configuration • A-2 


Network (cont'd.) 

normal memory requirements • 5-32 
object • 3-2 
passwords* 2-39 
restrictions on mixed *2-20, A-12 
security • 2-39 
shutting down *6-2 
terminal • 3-81 
testing • 7-1 
topology* 1-17 
user interface to* 1-20 
user operations* 1-20, 8-1 
worst-case memory requirements • 5-34 
Network configuration procedure • 5-12 to 5-29 
Network connect block 
See NCB 

Network Control Program 
See NCP 
Network driver 
See NETDRIVER 

Network Information and Control Exchange 
See NICE 
Network interface 

VAX/VMS operating system* 1-2 
Network management 
functions* 1-3 
responsibilities* 1-14 
Network name 

declaring • 8-26, 8-36 
Network process failures 
potential causes *2-31 
NETWORK qualifier 

for X.25 access module *3-79 
Network server process *2-30 
Network Services Program 
See NSP 
Network task 

declaring • 8-7, 8-11, 8-26 
NICE (Network Information and Control Exchange)* 
3-3 

NICONFIG (Ethernet Configurator)* 1-15 
NML (network management listener)* 1-16, 2-29, 
6-1 

access control *3-87 
Node* 1-1, 1-19, 3-7 

address*2-2, 2-22, 3-7, 3-61, A-12 
address conversion • 3-61 
addressing Cl node *3-32 
adjacent* 1-1, 2-20 
alias node identifier 

See Alias node identifier 
area number *2-2 
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Node (cont'd.) 

automatic configuration • 5-4 
bringing up DECnet-VAX node *6-1 
changing local address *3-9 
checking type* 1-9, 2-42, 3-89 
clearing or purging database before copying 
3-21 

commands • 3-4 

configuring for DECnet-VAX* 1-17 
conversion of Phase IV address *2-22 
copying database* 1-17, 2-3, 3-20 
counters* 3-24 
database* 3-1 

default access account* 1-24 

definition • 2-1 

displaying network *8-1 

display of type *3-60 

end node* 1-1, 2-19 

Ethernet address *2-2, 3-1 1 

executor*2-2, 3-5 

identification • 2-2, 2-22, 3-7 

initialization request *3-38 

local node* 1-14, 1-20, 2-2, 3-5 

logical name in file specification* 1-25 

name*2-2, 3-7 

non-Ethernet* 1-7 

nonrouting • 2-20 

number*2-2, 2-22, 3-7 

number in Ethernet address *3-12 

parameters • 2-3, 3-14 

phases *2-20 

reachable *2-25 

remote *3-38 

remote node* 1-14, 1-20, 2-2, 3-5 

removing remote name and address *3-9 

routing* 1-1, 2-19, 2-20 

shutting down DECnet-VAX node *6-2 

specification access control string* 1-23 

specification string for node* 1-23 

state *2-3, 3-20 

type *2-20, 3-60 

X.25 connector* 1-3 

X.25 host* 1-3 

Node-level access control *2-40 
Node-level loopback test *7-1 
logical link operation • 7-1 
over specific circuit *7-1 
NODE parameter*7-9 

for X.25 host node*3-78 
identifying X.25 connector• 3-80 
NODRIVER*2-14, 5-3, 5-7 
Nonpaged dynamic memory pool *5-32 


Nonprivileged access control string *2-37 
Nonrouting node 
See End node 
Nontransparent 

communication* 1-23 
user network operations* 1-20 
Nonzero object *2-29 
NPAGEDYN parameter • 5-32 
NSP (Network Services Program) 

message retransmission • 2-28, 3-68 
receive buffers *3-17 
NUMBER parameter 

for DECnet objects *3-70 
for DLM circuit *3-45 
for GROUP *3-30 


o 


Object *1-19 

access control *2-30 
addressing • 2-29 

command procedure for DECnet-VAX • 2-29, 
3-72 

command procedure for PSI*2-32 

commands *3-70 

database *3-2 

DECnet-VAX *2-29 

definition • 2-28 

identification • 3-70, 3-73 

name*2-28, 3-70 

network • 2-28, 3-2 

nonzero*2-29, 3-70 

number*8-26, 8-36 

parameters* 3-70 

proxy login access *2-42 

PSI account information • 2-32 

TASK *2-29, 3-70 

type *2-28, 8-10 

type number*2-29, 3-70 

user-defined • 2-28 

use with alias node identifier • 2-30, 3-71 
VAX PSI *2-28, 2-32, 3-73 
zero-numbered • 2-29, 3-70 
OBJECT parameter • 3-78 

OPCOM (Operator Communication Facility) • 2-35, 
3-81, 6-3 
Operational state 
of circuit • 3-36 
of lines *3-52 
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Operator Communication Facility 
See OPCOM 

Operator-initiated downline load *4-1, 4-5 
OPER privilege • 5-2 
Outbound logical link connection* 1-24 
Outgoing call 

from DTE *3-26 

OUTGOING TIMER parameter • 3-68 
Overlaying RSX-1 IS tasks*4-20 
OWNER EXECUTOR parameter 
for DLM circuit *3-45 


p 


P/OS node*9-5 

Packet assembly/disassembly facility 
See PAD 

Packet size parameters • 3-27 
Packet switching data network 
See PSDN 

PAD (packet assembly/disassembly facility)* 1-3, 
3-76 

Partitioned area problem* A-10 
example of • A-1 1 
Password 

for dynamic connection • 2-36, 2-42 
receive*2-36, 3-86 

routing initialization* 1-9, 2-20, 2-36, 3-86, 

A-14 

transmit • 2-36, 3-86 
Path *2-25 

Path control parameters • 3-64 
for areas • 3-65 

Permanent database* 1-16, 3-2, 5-38 
considerations • 5-38 
copying node entries *3-21 
Permanent virtual circuit 
See PVC 

Phase III node*2-20 

in Phase IV network* A-12 
restrictions* A-12 
Phase II node*2-20 
Phase IV 

end node *2-21 
node* 2-20 
node address *2-22 
router • 2-21 

PHONE object *2-4, 2-29, 2-30, 3-71 
Physical address 

Ethernet* 1-7, 3-1 1, 3-13 


PHYSICAL ADDRESS parameter 
for LOOP CIRCUIT command *7-9 
for TRIGGER command *4-6 
Pipeline quota *2-28, 3-69 
PIPELINE QUOTA parameter 

SET EXECUTOR command *3-69 
Point-to-point 
circuit* 2-6 

configuration • 1-4, 1-7, 5-13 
DDCMP addressing • 3-32 
line* 2-13 

security for connection • 2-42, 3-86 
Polling* 1-7, 2-8 

POLLING STATE parameter • 3-39 
Primary loader *4-2 
PRIORITY parameter*3-77 
Privilege 
ACNT • 5-2 
BYPASS *5-2 
CMKRNL* 5-2 
DETACH *5-2 
DIAGNOSE *5-2 
for access control *2-37 
for network operations • 5-2 
NETMBX • 2-38, 5-2 
OPER *5-2 

required for NCP commands*2-39 
SECURITY *5-2 
SYSNAM • 5-2 
SYSPRV • 5-2 
TMPMBX • 2-38, 5-2 
to configure network *5-2 
to issue CLEAR ALL or PURGE command *2-39 
to issue SET ALL or DEFINE command *2-39 
to modify permanent database • 2-39 
to modify volatile database • 2-39 
to start the network *2-39 
Program load request *4-2 
over Ethernet *4-2 
Programming language 

in network application* 1-21 
selecting for network operation* 1-22 
Protocol module 
See X.25 

PROTOCOL parameter*3-49 

Protocols* 1-4 

Proxy 

access* 2-41 

access display for executor • 3-89 
access display for object *3-90 
access file specification • 3-89 
account* 2-41 
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Proxy (cont'd.) 

login • 2-41 
Proxy login 

access control* 1-24, 2-41 
access control commands • 3-89 
account* 2-41 
control • 2-41 

DEFAULT PROXY parameter • 2-41 
enabling access *2-41 
NETUAF.DAT *2-41 
PROXY parameter* 2-42 
PROXY parameter*3-89 

SET OBJECT command *2-42 
PSDN (packet switching data network)* 1-1, 1-3, 
1-4, 1-12, 2-5 
identification • 3-79 
installation • 6-2 

PSIACP (PSI ancillary control process)* 1-16 
PSI ancillary control process 
See PSIACP 
PSIKDA 

KMS/KMV Dump Analyzer* 7-13 
PURGE EXECUTOR command *3-17 
PVC (permanent virtual circuit)* 1-12, 2-7, 2-11 
parameters *3-43 


Q 


QNA 

Ethernet circuit device *2-10 
Ethernet line device *2-18 
Quota 

pipeline • 2-28, 3-69 


R 


RCF (remote console facility) 
error messages • 4-21 
invoking • 4-21 
Reachable node *2-25 
RECALL TIMER parameter • 3-45 
Receive buffers *3-17 
RECEIVE BUFFERS parameter 
for DDCMP line *3-54 
for X.25 line *3-59 
Receive password • 2-36 
Remote command execution • 3-5 
Remote console connection • 4-20 
Remote file access* 1-20, 8-1 


Remote file operations 

general DECnet-VAX restrictions • 9-1 
heterogeneous network *9-1 
VAX/VMS to VAX/VMS 

Version 4.4 to previous version *9-24 
Version 4 to Version 3*9-23 
VAX/VMS to IAS *9-2 
VAX/VMS to P/OS *9-5 
VAX/VMS to RSTS/E • 9-6 
VAX/VMS to RSX (using FCS-based FAL)* 

9-1 1 

VAX/VMS to RSX (using RMS-based FAL) *9-9 
VAX/VMS to RT-1 1*9-14 
VAX/VMS to TOPS-10*9-17 
VAX/VMS to TOPS-20* 9-20 
Remote node* 1-14, 1-20, 2-2, 3-5 
copying database • 2-3, 3-20 
loopback test • 7-2 
setting name and address *3-7 
RESET TIMER parameter • 3-29 
Responsibilities of system manager* 1-14 
RESTART TIMER parameter • 3-29 
Retransmit timer *3-54 
formula for*3-55 
RMS calls* 1-21 
Router* 1-1, 1-15, 3-40, 6-1 
area* 1-2, 2-21 
definition *2-19 
designated* 1-7, 2-19, 2-24 
Ethernet* 1-7, 2-24 
level 1 • 1-2, 2-19, 2-21, A-1 
level 2* 1-2, 2-19, 2-21, A-1 
on VAXcluster* 1-11 
Phase IV *2-21 

redundant level 2 routers *A-3 
ROUTER PRIORITY parameter*3-41 
Route-through control *3-64 
Routing *2-19 
area • 1-2 

broadcast message timer *2-27 
commands *3-60 
concepts *2-25 

configuration considerations *2-19 

control parameters • 3-62 

cost • 2-25 

definition *1-1 

hop* 2-25 

initialization passwords • 2-20, 2-36, 2-42, 
3-86, A-14 
maximum visits *2-26 
message• 2-27, 3-65 
message timer *2-27 
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Routing (cont'd.) 
parameters* 2-25 
path *2-25 

path control parameters*3-64 

path cost *2-25 

path length*2-25 

reachable node *2-25 

route-through control parameters*3-64 

segmented message *2-27 

setting configuration limits *3-61 

timer* 3-65 

timing of messages • 2-27 
verification • 3-37 

Routing initialization password* 1-9 
Routing node *2-19 
See Router 
Routing timer *2-27 
RSTS/E node *9-6 
RSX-1IS 

checkpointing tasks *4-20 
downline load of system *4-1 
NETGEN procedure • 4-16 
overlaying tasks *4-20 
task load *4-16 
RSX node *9-9, 9-11 
RT—11 node *9-14 


s 


Satellite Loader 
See SLD 

Satellite transmission control *3-55 
Scheduling timer *3-54 
Secondary loader*4-5, 4-10 
SECONDARY LOADER parameter • 4-12 
Security 

for dynamic asynchronous connection* 1-9 
for point-to-point connection • 2-42, 3-86 
protecting network configuration files *2-39 
SECURITY privilege *5-2 
SEGMENT BUFFER SIZE parameter 
for executor *3-18 
SENDING ADDRESS parameter 
for DTE *3-75 
Server module 

See X.25 server module and X.29 server 
module 

Service 

circuit identification for downline load *4-13 
device identification for downline load *4-13 


Service (cont'd.) 

operations for circuit *3-37 
password for downline load *4-13 
SERVICE CIRCUIT parameter *4-6 
SERVICE DEVICE parameter *4-13 
Service timer *3-54 
SET CIRCUIT command 

CHANNEL parameter*3-43 
COST parameter *3-62 
COUNTER TIMER parameter • 3-47 
DTE parameter *3-43 
MAXIMUM BUFFERS parameter • 3-40 
MAXIMUM DATA parameter • 3-44 
MAXIMUM RECALLS parameter • 3-45 
MAXIMUM ROUTERS parameter • 3-41, 3-61 
MAXIMUM TRANSMITS parameter • 3-40 
MAXIMUM WINDOW parameter • 3-44 
NUMBER parameter*3-45 
OWNER EXECUTOR parameter • 3-45 
polling control parameters • 3-39 
POLLING STATE parameter • 3-39 
RECALL TIMER parameter • 3-45 
ROUTER PRIORITY parameter • 3-41 
SERVICE parameter*3-37, 4-5, 4-15 
STATE parameter*3-36, 4-15 
TRIBUTARY parameter • 3-32 
TYPE parameter*3-43 
USAGE parameter*3-43, 3-46 
VERIFICATION INBOUND parameter • 3-38, 

3-86 

VERIFICATION parameter• 3-37 
SET EXECUTOR command 

ADDRESS parameter*3-7, 3-61 
ALIAS INCOMING parameter*3-10 
ALIAS MAXIMUM LINKS parameter • 3-67 
ALIAS NODE parameter • 3-10 
AREA MAXIMUM COST parameter • 3-65 
AREA MAXIMUM HOPS parameter • 3-65 
BROADCAST ROUTING TIMER parameter • 3-66 
BUFFER SIZE parameter*3-8, 3-17 
COUNTER TIMER parameter • 3-24 
DEFAULT ACCESS parameter • 2-40, 3-88 
DEFAULT PROXY parameter*2-41, 3-89 
DELAY FACTOR parameter • 3-68 
DELAY WEIGHT parameter • 3-68 
IDENTIFICATION parameter • 3-8 
INACTIVITY TIMER parameter • 3-68 
INCOMING TIMER parameter • 3-68 
local node address *3-7 
MAXIMUM ADDRESS parameter • 3-8 
MAXIMUM AREA parameter • 3-62 
MAXIMUM BROADCAST NONROUTERS 
parameter* 3-62 
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SET EXECUTOR command (cont'd.) 

MAXIMUM BROADCAST ROUTERS parameter* 
3-62 

MAXIMUM BUFFERS parameter • 3-19 
MAXIMUM CIRCUITS parameter • 3-19 
MAXIMUM COST parameter • 3-64 
MAXIMUM HOPS parameter • 3-64 
MAXIMUM LINKS parameter • 3-67 
MAXIMUM VISITS parameter • 3-64 
OUTGOING TIMER parameter*3-68 
PIPELINE QUOTA parameter • 3-69 
RETRANSMIT FACTOR parameter • 3-68 
ROUTING TIMER parameter • 3-65 
SEGMENT BUFFER SIZE parameter*3-18 
STATE parameter*3-20, 6-2 
SUB ADDRESSES parameter • 3-46 
SET EXECUTOR NODE command *3-5 
access control information • 3-88 
SET HOST command 

heterogeneous command terminal* 1-21, 8-2 
SET LINE command 

BUFFER SIZE parameter• 3-17, 3-53 
CONTROLLER parameter • 7-12 
DUPLEX parameter*3-54 
INTERFACE parameter • 3-59 
MAXIMUM BLOCK parameter • 3-58 
MAXIMUM DATA parameter• 3-57 
MAXIMUM RETRANSMIT parameter• 3-57 
MAXIMUM WINDOW parameter • 3-58 
MICROCODE DUMP parameter*7-13 
PROTOCOL parameter*3-49, 3-50 
RECEIVE BUFFERS parameter • 3-54 
SERVICE TIMER parameter• 4-5, 4-15 
STATE parameter*3-53, 7-12 
TRANSMIT PIPELINE parameter• 3-55, 3-69 
SET LOGGING command *3-90 
EVENTS parameter*3-82, 3-84 
NAME parameter *3-81 
STATE parameter*3-83 
SET LOGGING EVENTS command *3-81 
SET LOGGING MONITOR command 
SINK parameter*3-83 
SET LOGGING STATE command *3-81 
SET MODULE CONFIGURATOR command 
KNOWN CIRCUITS parameter • 3-43 
STATUS display *3-42 
SURVEILLANCE DISABLED parameter • 3-43 
SURVEILLANCE ENABLED parameter • 3-42 
SET MODULE X25-ACCESS command 
ACCOUNT parameter*3-80 
NETWORK qualifier *3-79 
NODE parameter*3-80 


SET MODULE X25-ACCESS command (cont'd.) 
PASSWORD parameter*3-80 
USER parameter • 3-80 

SET MODULE X25-PROTOCOL command *3-24 
CALL TIMER parameter • 3-28 
CLEAR TIMER parameter • 3-28 
DEFAULT DATA parameter • 3-27 
DEFAULT WINDOW parameter• 3-27 
DTE qualifier*3-25 
GROUP qualifier*3-30 
MAXIMUM CLEARS parameter • 3-28 
MAXIMUM DATA parameter • 3-27 
MAXIMUM RESETS parameter • 3-29 
MAXIMUM RESTARTS parameter • 3-29 
MAXIMUM WINDOW parameter• 3-27 
RESET TIMER parameter • 3-29 
RESTART TIMER parameter • 3-29 

SET MODULE X25-SERVER command 
CALLED ADDRESS parameter• 3-77 
CALLED DTE parameter• 3-77 
CALL MASK parameter • 3-76 
CALL VALUE parameter • 3-76 
DESTINATION qualifier • 3-74 
EXTENSION MASK parameter • 3-76 
EXTENSION VALUE parameter • 3-76 
GROUP parameter*3-75 
INCOMING ADDRESS parameter• 3-77 
MAXIMUM CIRCUITS parameter• 3-78 
NODE parameter*3-78 
OBJECT parameter*3-78 
PRIORITY parameter*3-77 
RECEIVING DTE parameter• 3-77 
REDIRECT REASON parameter• 3-77 
SENDING ADDRESS parameter• 3-75, 3-77 
STATE parameter*3-79 
SUBADDRESSES parameter • 3-75 

SET NODE command *7-3 

ACCESS parameter • 2-40, 3-88 
ADDRESS parameter • 3-4, 3-8 
COUNTER TIMER parameter • 3-24 
DIAGNOSTIC FILE parameter • 4-13 
HARDWARE ADDRESS parameter• 4-6, 4-8 
INBOUND parameter*3-89 
NAME parameter*3-7 
NONPRIVILEGED parameter • 3-87 
PRIVILEGED parameter *3-87 
RECEIVE PASSWORD parameter • 3-86 
remote node name and address *3-7 
SERVICE CIRCUIT parameter • 4-8 
SERVICE DEVICE parameter • 4-13 
SERVICE PASSWORD parameter*4-13 
SOFTWARE IDENTIFICATION parameter • 4-12 
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SET NODE command (cont'd.) 

SOFTWARE TYPE parameter • 4-12 
TRANSMIT PASSWORD parameter • 3-86 
SET OBJECT command 

ACCOUNT parameter*3-74 
ALIAS INCOMING parameter*3-10, 3-71 
ALIAS OUTGOING parameter*3-10, 3-71 
FILE parameter • 3-73 
NUMBER parameter • 3-70 
PASSWORD parameter*3-74, 3-87 
PRIVILEGE parameter *3-87 
PROXY parameter*2-42, 3-89 
USER parameter*3-74, 3-87 
SHOW command *3-90 

SHOW EXECUTOR CHARACTERISTICS command 
display of proxy access *3-89 
SHOW EXECUTOR command 

CHARACTERISTICS display *3-8 
display of Ethernet address *3-12 
display of executor type *3-60 
SHOW LINE command 

Ethernet hardware address • 3-57, 7-10 
SHOW MODULE CONFIGURATOR command* 
3-41, 3-42 

SHOW NETWORK command *8-1, 8-2 
display of network status *8-1 
SHOW NODE command 

COUNTERS parameter*3-24 
display of node type *3-60 
Sink *2-34 

logging • 2-35, 3-81 
name* 2-35 
node* 2-35 
related event • 2-34 
state* 2-35 
SINK parameter*3-83 
Slave node *4-14 
SLD (Satellite Loader) *4-16 
building *4-16 

SOFTWARE IDENTIFICATION parameter*4-12 

Software loopback test *7-6, 7-7 

Source-related event *2-34 

Source task *8-10 

STARTNET.COM *5-4, 5-13, 6-2 

State 

logging • 3-83 
of circuit • 2-7 
of line *2-12 
of local node • 2-3 
STATE parameter 
for circuit • 3-36 
for DTE *3-25 
for executor node *3-20 


STATE parameter (cont'd.) 
for line *3-52 

for X25-SERVER module *3-79 
Static asynchronous connection* 1-4, 1-7, 1-9 
network configuration *5-17 
reasons for failure *5-9 
Static asynchronous line* 1-9, 2-14, 5-8 
installing • 5-8 
shutting down *5-9 
STATUS display type *3-91 
Stream timer *3-54 
SUBADDRESSES parameter 

for SET EXECUTOR command *3-46 
for X25-SERVER module *3-75 
SUMMARY display type *3-91 
SVC (switched virtual circuit)* 1-12, 2-7, 2-11 
for DLM use*2-7, 2-1 1 
for X.25 native use*2-7 
Switched virtual circuit 
See SVC 

SWITCH parameter*3-56 
Synchronous connection* 1-4 
Synchronous disconnect• 8-9, 8-13, 8-28, 8-34 
SYSSASSIGN • 5-2, 8-16 
format*8-18, 8-29 
_NET: • 8-29 

nontransparent use of *8-23 
transparent use of *8-16 
SYS$CANCEL* 8-28 
SYSSCREMBX • 5-2, 8-23 
SYSSCREPRC • 5-2 

SYSSDASSGN*8-13, 8-17, 8-21, 8-37 
format* 8-21 
SYSSGETDVI • 8-29 

SYSSLOGIN: NETSERVER.LOG *2-31,4-19 
SYS$LOGIN:objectname.COM • 3-72 
SYS$MANAGER:EVL.LOG • 3-84 
SYS$MANAGER:NET.LOG • 3-92 
S YS$M AN AGER: NETCONFIG.COM • 5-5 
SYSSMAN AGER:RTTLOAD.COM • 6-1 
SYS$MANAGER:STARTNET.COM • 5-6, 5-13, 6-1 
SYSSNET *8-11, 8-17, 8-26 
SYSSQIO 

format *8-30, 8-31, 8-32, 8-34, 8-35, 8-36 
IO$_ACCESS• 8-24, 8-27, 8-30, 8-31 
IO$_ACCESS!IO$M_ABORT*8-27, 8-32 
IO$_ACPCONTROL* 8-27, 8-36 
IO$_DEACCESS!IO$M_ABORT • 8-28, 8-29, 
8-35 

IO$_DEACCESS!IO$M _SYNCH • 8-34 
IO$_READVBLK • 8-33 
IO$_WRITEVBLK • 8-33 
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SYS$QIO (cont’d.) 

IO$_WRITEVBLK! IO$M_INTERRUPT • 8-28, 
8-34 

SYS$QIO(IO$_ACCESS!IO$M_ABORT) • 8-27 
format* 8-32 

SYS$QIO(IO$_ACCESS) • 8-24, 8-27 
format *8-30, 8-31 
SYS$QIO(IO$_ACPCONTROL) • 8-27 
format* 8-36 

SYS$QIO(IO$_DEACCESS!IO$M—ABORT) • 8-28, 
8-29 

format • 8-35 

SYS$QIO(IO$_DEACCESS!IO$M—SYNCH) 
format • 8-34 

SYS$QIO(IO$_READVBLK) • 8-33 
format* 8-20 

SYS$QIO(IO$_WRITEVBLK! IO$M_INTERRUPT) 
format* 8-34 

SYS$QI0(I0$_WRITEVBLK) • 8-33 
format* 8-19 

SYS$SYSTEM:objectname.COM • 3-72 
SYS$SYSTEM:SYSGEN 
See SYSGEN 

SYS$TRNLOG system service call *8-1 1 
SYSGEN 

IRPCOUNT parameter* 5-32 
LRPCOUNT parameter* 5-32 
LRPSIZE parameter* 5-32 
NPAGEDYN parameter • 5-32 
running • 5-32 

updating parameters for DECnet*5-32 
SYSNAM privilege *5-2, 8-27 
SYSPRV privilege *5-2, 5-5 
System configuration guidelines*5-31 to 5-38 
System-level access control *2-37 
System management 
responsibilities* 1-14 
VAX PSI* 1-14, 5-4 
System service call* 1-21, 8-13, 8-21 

summary for nontransparent use *8-22, 8-29 
summary for transparent use *8-15, 8-18 


T 


Tailoring the configuration database *5-7 
Target-initiated downline load *4-2 
Target node *4-1 
Target task* 8-10 
Task 

declaring for network *8-7 
definition • 1 -20 


Task (cont'd.) 

downline load *4-16 
general purpose *4-18 
identifier in specification* 1-23 
installation *4-18 
source *8-12 
specification • 1-23 

specification access control string* 1-23 
specification for task* 1-23 
specification over the network* 1-23 
target*8-12, 8-19 

Task-to-task communication • 1-3, 1-20, 8-1, 
8-13, 8-21 

nontransparent• 8-6, 8-7, 8-21 
nontransparent MACRO example *8-43 
transparent • 8-1, 8-13 
transparent FORTRAN example *8-38 
transparent MACRO example *8-41 
TELL prefix 

description • 3-6 

Terminal, heterogeneous command *8-1 
Terminal connection 

to remote console *4-20 
Terminal emulator* 1-9, 2-16 
Terminal line 

conversion to DECnet line* 1-9, 2-14, 5-7 
Terminal server 
LAT* A-10 
on Ethernet* 1-11 
Tertiary loader *4-4, 4-10 
Test 

circuit loopback test *7-6, 7-9 
controller loopback test *7-8 
Ethernet loopback test *7-9 
local loopback test *7-5 
local-to-remote test *7-3 
node-level test *7-1 
remote loopback test *7-2 
software loopback test *7-7 
X.25 test *7-12 
Testing the network *7-1 
Timer 

babble *3-40 

broadcast routing *3-66 

call *3-28 

clear • 3-28 

counter • 3-24 

dead• 3-54 

delay • 3-54 

hello *3-37 

inactivity • 2-28, 3-68 

incoming • 2-28, 3-68 

line • 3-54 
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Timer (cont'd.) 
logical link *2-28 
outgoing • 2-28, 3-68 
recall • 3-45 
reset* 3-29 
restart* 3-29 
retransmit *3-54, 3-57 
routing • 2-27, 3-65 
scheduling • 3-54 
service* 3-54 
stream • 3-54 
transmit • 3-40 
TLK image *4-16 
TMPMBX privilege *2-38 
Topology 

of a multiple-area network* 1-17 
of a single-area network* 1-17 
TOPS-10 node *9-17 
TOPS-20 node *9-20 
TO qualifier 

COPY KNOWN NODES command *3-21 
TQELM quota *5-34 
Transmit password • 2-36 
TRANSMIT PIPELINE parameter • 3-55 
Transmit timer *3-40 
Transparent 

communication* 1-23, 8-1 
user network operations* 1-20 
Tributary* 1-7, 2-8 
address* 2-8 
circuit timers *3-40 
control *3-39, 3-40 
TRIBUTARY parameter • 3-32 
TRIGGER command *4-2, 4-6 

PHYSICAL ADDRESS parameter• 4-6 
SERVICE PASSWORD parameter • 4-6 
Trigger message *4-2 
Trigger operation 

bootstrap ROM • 4-3 
primary bootstrap *4-2 
primary loader *4-2 
TRIGGER command *4-6 
TRIGGER VIA command *4-13 
TYPE parameter 

for executor node *3-60 
for GROUP *3-31 
for PVC • 3-43 


u 


UAF (user authorization file) *8-11 

creation of default nonprivileged DECnet 
account• 5-1 

UETP (User Environment Test Package) • 5-6, 6-2 
UNA 

Ethernet circuit device *2-10 
Ethernet line device *2-18 
loopback test*7-9 
Unattended system 
memory dump *4-14 
slave *4-14 
UNIBUS 

devices* 5-36 
map registers*5-36 
Upline memory dump 
definition *4-14 
over Ethernet *4-15 
procedures *4-14 
requirements *4-15 
RSX-1 IS system*4-14 
USAGE parameter 
for DLM circuit *3-46 
for PVC • 3-43 
User 

interface to network* 1-20 
network operations • 8-1 
transparent network operations* 1-20 
User-defined object *2-28 
User Environment Test Package 
See UETP 
User group 

See BCUG, CUG, and X.25 
USING qualifier 

COPY KNOWN NODES command *3-21 


v 


VAXcluster 

configuration *1-10 
end node* 1-1 1, 2-25 
router* 1-11, 2-25 
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VAXcluster (cont'd.) 

use of an alias node identifier* 1-11, 2-4, 2-30, 
3-9, 8-7 

use of Cl data link* 1-10 
use of DECnet-VAX data link* 1-10 
VAX Packetnet System Interface 
See VAX PSI 
VAX PSI* 1-3 

bringing up a DTE *6-2 

command procedure for object *2-32 

configuration* 1-4, 1-17, 5-1, 5-26, 5-30 

connector node *6-2 

database* 1-16, 3-3 

dumping KMS11 microcode* 7-1, 7-13 

dumping KMVI 1 microcode • 7-1, 7-13 

line-level loopback test *7-1, 7-12 

multihost installation • 6-2 

multihost mode* 1-3, 1-14, 5-1 

multinetwork configuration • 5-30 

native mode* 1-3, 1-14 

native user programs *2-7 

object*2-32, 3-73 

software* 1-15, 2-1 

system management* 1-14, 5-4 

test facilities* 7-1 

users* 1-14 

VAX PSI Access software* 1-12, 2-1, 2-6, 2-34, 
5-1, 6-2 

VAX/VMS node *2-1 
VAX/VMS operating system 
network interface* 1-2 
nonpaged dynamic memory pool *5-32 
VAX/VMS to VAX/VMS network operation 
Version 4.4 to previous version *9-24 
Version 4 to Version 3*9-23 
VAX/VMS to IAS network operation • 9-2 
VAX/VMS to P/0S network operation • 9-5 
VAX/VMS to RSTS/E network operation • 9-6 
VAX/VMS to RSX (using FCS-based FAL) network 
operation* 9-11 

VAX/VMS to RSX (using RMS-based FAL) 
network operation • 9-9 
VAX/VMS to RT-11 network operation • 9-14 
VAX/VMS to TOPS-10 network operation • 9-17 
VAX/VMS to TOPS-20 network operation • 9-20 
VERIFICATION INBOUND parameter • 3-38, 3-86 
VERIFICATION parameter • 3-38 
Virtual circuit* 1-6, 1-8 

See also X.25 virtual circuit 
Virtual terminal* 1-9, 2-16 
enabling* 5-10 
VMR *4-16 


Volatile database* 1-16, 3-2 
copying node entries *3-21 
display information • 3-90 
use of *3-2 


w 


Wildcard character 
for events*3-82 
Window size parameter• 3-27 
WITH qualifier 

COPY KNOWN NODES command *3-21 


x 


X.25* 1-3, 2-5 

access module* 1-19, 2-6, 2-34 
access module commands • 3-79 
BCUG • 2-6, 3-30, 3-75 
call destination • 2-32 
CCITT recommendation* 1-3, 1-12 
circuit *2-6, 3-33 
circuit devices *2-11 
circuit identification • 3-33 
circuit parameters *3-43 
connector node* 1-1, 1-3, 1-4, 1-12, 1-17, 
2-1, 2-6, 2-32, 2-34, 3-78, 3-79, 5-1, 6-2 
connector node configuration • 5-26 
CUG • 2-6, 3-30, 3-75 
data packet control • 3-27, 3-44 
gateway node* 1-3, 5-1 
handling incoming calls *3-74 
host node* 1-3, 1-12, 1-17, 2-1, 2-6, 2-32, 
2-34, 3-78, 3-79, 5-1 
host node configuration • 5-26 
LAPBE line protocol • 3-49 
LAPB line protocol • 3-49 
line*2-11, 2-12, 3-50 
line device *2-18 
line-level loopback test *7-12 
line parameters*3-57 
line receive buffers *3-59 
multihost installation • 6-2 
multihost mode* 1-12, 2-6, 5-1 
multihost mode network configuration • 5-26 
multinetwork configuration • 5-30 
native mode* 1-12 

native-mode network configuration • 5-25 
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X.25 (corn'd.) 

protocol module* 1-19, 2-1, 2-5, 3-24 
PSDN • 1-1 

PVC • 2-7, 2-11, 3-33 
server module* 1-19, 2-5, 2-6, 2-32 
server module commands • 3-74 
SVC• 2-7, 2-11, 3-33 
trace module* 1-19 
user group *2-6, 3-30, 3-75 
virtual circuit* 1-1, 1-3, 1-12,2-7,2-11 
X.29 

CCITT recommendation • 1-3, 1-12 
incoming calls *3-76 
server module* 1-19, 2-5, 2-32 
server module commands • 3-74 
terminal* 1-12 
X25-PROTOCOL module 
commands *3-24 
counters • 3-31 
parameters • 3-24 
X25-SERVER module 
identification • 3-74 
parameters* 3-74 
X29-SERVER module 

See X25-SERVER module 



ZERO CIRCUITS command *3-48 
ZERO EXECUTOR command *3-24 
Zeroing 

line counters • 3-60 
node counters*3-24 
ZERO LINE command *3-60 
ZERO NODE command *3-24 
Zero-numbered object *2-29 
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